π‘«π’†π’‚π’…π’π’π’„π’Œ π’–π’”π’Šπ’π’ˆ π’‡π’Šπ’‡π’

Posted on by Yashwanth Naidu Tikkisetty

In this post, let’s set up a scenario using two FIFOs and a client-server model to demonstrate a deadlock situation.

The server waits for the client to send a message on one 𝑭𝑰𝑭𝑢 (𝒍𝒆𝒕’𝒔 𝒄𝒂𝒍𝒍 π’Šπ’• π’‡π’Šπ’‡π’πŸ). At the same time, the client waits for a message from the server on another 𝑭𝑰𝑭𝑢 (π’‡π’Šπ’‡π’πŸ). This creates a situation where both are waiting for each other to send a message, thus causing a deadlock.

The server expects the client to write to π’‡π’Šπ’‡π’πŸand then π’‡π’Šπ’‡π’πŸ. The client, however, writes to π’‡π’Šπ’‡π’πŸ first and then tries to write to π’‡π’Šπ’‡π’πŸ. Both processes end up waiting for each other to read from the FIFOs they wrote to, resulting in a deadlock.

What to expect when you run it?

1. When you run the 𝒔𝒆𝒓𝒗𝒆𝒓.𝒄 Β program, it will first try to read from π’‡π’Šπ’‡π’πŸ. Since nothing has been written to π’‡π’Šπ’‡π’πŸ yet, it will block and wait for some data to be written.

Picture 1

2. When you run the π’„π’π’Šπ’†π’π’•.𝒄 program, it will immediately try to write to π’‡π’Šπ’‡π’πŸ. However, the server is not reading from π’‡π’Šπ’‡π’πŸ yet; it’s still waiting on π’‡π’Šπ’‡π’πŸ. So, the client will block at this point too.

Picture 2

3. As a result, both the server and the client will be stuck (deadlocked). (Picture 3) Neither will proceed, and you won’t see any output from either program.

Picture 3

So, how to we know if we are getting what we were expecting?

We can do this by echo “Test message” > π’‡π’Šπ’‡π’πŸ Β in another terminal.
(Picture 4)

Picture 4

What do you expect after the above?

1. The server successfully read from π’‡π’Šπ’‡π’πŸ and printed the message “Text message”. This means something (or someone) wrote to π’‡π’Šπ’‡π’πŸ before or while the server was waiting to read from it. It could have been an external input, like using the echo command previously seen, or perhaps from a previous run of the client.

2. After reading from π’‡π’Šπ’‡π’πŸ, the server moved on to read from π’‡π’Šπ’‡π’πŸ.

3. When you run the client, it successfully wrote the message “Hello from client on fifo2!” to π’‡π’Šπ’‡π’πŸ, which the server then read and printed.

4. Both programs completed their main execution flow after this, so they both exited. (Picture 4)

There was no deadlock in this scenario because the condition for the deadlock (server waiting on π’‡π’Šπ’‡π’πŸ while the client writes to π’‡π’Šπ’‡π’πŸ first) wasn’t met. Instead, the server was able to read from π’‡π’Šπ’‡π’πŸ Β and then move on to read from π’‡π’Šπ’‡π’πŸ.

LinkedIn Post: https://www.linkedin.com/posts/t-yashwanth-naidu_earlycareer-embeddedsystems-learning-activity-7107564749336301568-TdCw/?utm_source=share&utm_medium=member_desktop

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
An Article by: Yashwanth Naidu Tikkisetty
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Leave a Reply

Published by Yashwanth Naidu Tikkisetty

A Cosmic Being who blogs.