Need advice regarding race condition

Question

5.00/5 (2 votes)

See more:

Hi all,

I'm currently debugging a ship monitoring system. In that application I found whole heaps of bugs, fortunately I can solve every single one of them, except this one. So please help me.

Here's the explanation:
The bug is located within a distribution server, and I suspect (No, I'm sure of it) that there's an extreme race condition between the receiver class (will be addressed as Receiver) and sender class (will be addressed as Sender).

Distribution server works like this:
1. Receiver receive data.
2. Receiver write data into a data storage class (will be addressed as DataStorage).
3. Sender check whether DataStorage is empty or not.
4. If DataStorage is not empty, Sender will proceed to send the data.
Or so they think.

Problems I found so far:
1. A guaranteed race condition 'cause Sender check using a flag.
Okay, I've applied a lock into Sender.
2. I can't safely release Sender's lock.
Why? it's simple, really. It's because receiver works as interface. It receive data when onDataReceived method is called by a jar file (it's called QuickServer).

So here I am, looking for some advice regarding this matter. The only solution I've found so far is:
1. Release Sender's lock when a new data is received.
2. Sender will raise a flag to suspend any Receiver's incoming data.
3. Sender wait for any unfinished operation by Receiver (Thread.sleep(500)?).
4. Sender grab all data.
5. Sender pull down the flag.
6. Receiver start it's suspended operation, Sender process and send the data.
7. Everyone live in harmony till Sender's lock is re-applied after sending data therefore go back to step1.

[edit]My solution failed,[/edit]Is there any other solution? I'm a fresh graduate from a vocational high school therefore I'm looking for some experienced expert's solution.

Thanks in advance,

Firo A.V.

Posted 20-Jul-11 15:30pm

Firo Atrum Ventus

Updated 20-Jul-11 19:05pm

v7

Add a Solution

2 solutions

Solution 2

You can get some inspiration from here: http://en.wikipedia.org/wiki/Producer-consumer_problem[^]

Here your Receivers are the Producers and your Sender is a Consumer.

Posted 26-Jul-11 21:18pm

YvesDaoust

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Nagy Vilmos · Accepted Answer · 2011-07-20T21:46:00

Solution 1

You need to use a wait and notify[^] structure.
Simply put the when the sender gets to an empty queue, it goes into a wait state, and when the receiver adds something to the queue it notifies.

If all the Senders and Receivers are running within the same JVM, then you can ensure that someone gets the lock by putting all the logic in Synchronized blocks and using notifyAll() to wake up ALL the threads, rather than notify() which will wake up one and only one thread.

Posted 20-Jul-11 21:46pm

Nagy Vilmos

Updated 21-Jul-11 21:07pm

v2

Comments

Firo Atrum Ventus 21-Jul-11 21:33pm

The problem is the Receiver works as interface which called by QuickServer. There's so many thread that invoke Receiver so when I notify sender, other Receiver may processing the queue (which already removed by sender)

Nagy Vilmos 22-Jul-11 3:07am

Answer expanded to deal with more than two threads.