[Spread-users] Spread-users Digest, Vol 69, Issue 10

[John Riordan Cyber Solutions]

Unsubscribe

-------------------------------------------------------
twitter:   JohnbRiordan

On 23.09.2010, at 18:00, spread-users-request at lists.spread.org wrote:

> Send Spread-users mailing list submissions to
>    spread-users at lists.spread.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>    http://lists.spread.org/mailman/listinfo/spread-users
> or, via email, send a message with subject or body 'help' to
>    spread-users-request at lists.spread.org
> 
> You can reach the person managing the list at
>    spread-users-owner at lists.spread.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Spread-users digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Concurrency issues with spread 4 (John Schultz)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 22 Sep 2010 12:48:57 -0400
> From: John Schultz <jschultz at spreadconcepts.com>
> Subject: Re: [Spread-users] Concurrency issues with spread 4
> To: Johannes Wienke <jwienke at techfak.uni-bielefeld.de>
> Cc: spread-users at lists.spread.org
> Message-ID: <71BB8147-1D03-4AD7-BEDE-624AA1781C9E at spreadconcepts.com>
> Content-Type: text/plain; charset="us-ascii"
> 
> Johannes,
> 
> 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?
> 
> 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.)?
> 
> 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?
> 
> 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.
> 
> Cheers!
> 
> -----
> John Lane Schultz
> Spread Concepts LLC
> Phn: 301 830 8100
> Cell: 443 838 2200
> 
> On Sep 22, 2010, at 11:49 AM, Johannes Wienke wrote:
> 
> Dear all,
> 
> I'm currently struggling with some issues probably related to
> concurrency and would be glad to get some insight.
> 
> We're having one concurrently operating thread that constantly receives
> messages on an mbox and processes them. From other threads than the
> receiving, the memberships and lifecycle of the mbox are controlled.
> 
> Now I noticed a problem with the following sequence:
> 
> 1. [receiver thread] blocks in SP_receive
> 2. [other thread] joins mbox of receiving thread to a group
> 3. [other thread] directly after the join call sends a message to this group
> 
> Now the receiving thread does not receive the message sent by the other
> thread. If I add a short sleep between 2. and 3., the receiver thread
> gets the message.
> 
> So, is there no guarantee that a concurrently operating receiver thread
> receives every message directly sent after a join call from another
> thread? Or what is the reason for this behavior?
> 
> A second problem I encountered is how to interrupt the blocking call to
> SP_receive. Currently we're trying to interrupt SP_receive by
> disconnecting the mbox from another thread. Unfortunately this does not
> work in some cases and SP_receive endlessly hangs on the mbox. So again,
> is there no guarantee that SP_receive exits with an error if the
> underlying mbox is closed?
> 
> Thanks in advance for your help,
> Johannes
> 
> _______________________________________________
> Spread-users mailing list
> Spread-users at lists.spread.org
> http://lists.spread.org/mailman/listinfo/spread-users
> 
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 3805 bytes
> Desc: not available
> URL: <http://lists.spread.org/pipermail/spread-users/attachments/20100922/02b1928c/attachment-0001.bin>
> 
> ------------------------------
> 
> _______________________________________________
> Spread-users mailing list
> Spread-users at lists.spread.org
> http://lists.spread.org/mailman/listinfo/spread-users
> 
> 
> End of Spread-users Digest, Vol 69, Issue 10
> ********************************************