[Spread-users] Concurrency issues with spread 4

[Johannes Wienke]

On 09/22/2010 06:48 PM, John Schultz wrote:
> If steps 2+3 are performed by the same thread, then the receiver thread typically (depending on the msg's service type) should first get the join msg for the group (assuming membership tracking is enabled on the connection) and then the subsequent msg to that group.
>
> If steps 2+3 are performed by different threads and not coordinated to surely execute in a serial manner, then there is a race condition between the two threads accessing the server through the client library and the series of events you observe would certainly be possible.
>
> So, my first question is which of the above scenarios correctly describes your threading model and usage?

Joining and sending the message are preformed by the same thread, so the 
first of the scenarios you described is the correct one.

> My second question is what is the msg service type that you are using for sending the subsequent msg (e.g. - AGREED_MESS, UNRELIABLE_MESS, FIFO_MESS, etc.)?

RELIABLE_MESS.

> My third question is what do other, previously established members of the group observe as the series of events?  Do they see the join followed by the msg or vice versa, or what?

I did not check this so far.

> To your question about closing the file descriptor while another thread is blocked in a read, the behavior of that is OS dependent.  I have personally observed similar behavior to what you describe on certain OSes.  The safest way to disconnect such a receiver thread would be to send an application msg to the private group of the connection indicating that you want the reader to stop running (and call SP_close, clean up, etc.).  The receiver thread will get this message, process it and realize it should stop blocking on receives, etc.

Ok this is exactly what I've done now and for reasons I don't understand 
this also seems to have solved the first problem. I cannot reproduce the 
lost messages anymore eventhough this was the only change I've done.

Thanks for your help.
Johannes