[Spread-users] Win32 socket handle problems in multithreaded applications.

[John Lane Schultz]

I talked with the authors of the code and they agree with you that this can cause unnecessary blocking in the kinds of scenarios you describe.

The easiest way to (mostly) avoid this issue as a user is to use select/poll and only call SP_receive() on sockets that have data on them.  In those cases, the SP_receive() should almost always terminate quickly.

Otherwise, the synchronization code in the client library needs to be redone to give each socket its own dynamically allocated mutex.

Cheers!
John

---
John Lane Schultz
Spread Concepts LLC
Phn: 443 838 2200 
Fax: 301 560 8875

Wednesday, June 18, 2008, 3:47:21 AM, you wrote:

> Here’s the issue in pseudocode that will cause problem.
> ThreadB never receives any messages, hence the Mutex_lock(
> &Mbox_mutex[mbox & MAX_MUTEX_MASK][1] ); will never let ThreadA come through.
> ThreadA:
>                            While (…)          
> {
>                                                         mbox = 532; // 532 & MAX_MUTEX_MASK == 20
>                                                         SP_receive(mbox,.........);
> }
>  
> ThreadB:
>                            While (…)          
> {
>                                                         mbox =
> 1556; // 1556 & MAX_MUTEX_MASK == 20, same as threadA
>                                                         SP_receive(mbox,.........);
> }
>  
>  
> From: John Lane Schultz [mailto:jschultz at spreadconcepts.com] 
> Sent: den 17 juni 2008 18:56
> To: Dal, Mats
> Cc: spread-users at lists.spread.org
> Subject: Re: [Spread-users] Win32 socket handle problems in multithreaded applications.


>  
> This was done by design.  The assumption is not that socket handles
> won't be greater than 0xFF, but rather that 255 mutexes are enough
> to share within one application space.
>  
> You are correct that different socket handles will use the same
> mutexes, which can cause lock contention, but deadlock should be
> impossible because within the calls only one mutex is ever held (and released) by a thread.
>  
> Cheers!
> John
>  
> ---
> John Lane Schultz
> Spread Concepts LLC
> Phn: 443 838 2200 
> Fax: 301 560 8875
>  
> Tuesday, June 17, 2008, 7:30:13 AM, you wrote:
>  

> The mutex lock in “Sp.c” uses a dangerous assumption that doesn’t
> hold on Win32. The mbox will be assigned the opened win32 socket
> handle that could be greater than 0xFF, and for most time is.
>  
> int        SP_connect_timeout( const char *spread_name, const char *private_name,
>                           int priority, int group_membership, mailbox *mbox,
>                           char *private_group, sp_time time_out )
> {
> .
> s = socket( AF_UNIX, SOCK_STREAM, 0 );
> .
> *mbox = s;
> }
>  
>  
> The following code is bad on win32, masking with 0xFF will generate
> different socket handles using the same mutex and could cause
> deadlock during multithreaded applications.
>  
> int        SP_scat_receive( mailbox mbox, service *service_type, char sender[MAX_GROUP_NAME],
>                                   int max_groups, int *num_groups, char groups[][MAX_GROUP_NAME],
>                                   int16 *mess_type, int *endian_mismatch,
>                                   scatter *scat_mess )
> {
> .
> .
> Mutex_lock( &Mbox_mutex[mbox & MAX_MUTEX_MASK][1] );
> .
> .
> }
>  
>  
>  
> Mats Dal
> Senior Software Engineer 1
>  
> Tel 861
> Fax +46 8 658 78 99
> Cell 0709-549851
> Mats.Dal at dice.se
>  
> DICE
>  
> EA Digital Illusions CE AB
> Katarinavägen 15
> P.O. Box 20068
> SE-104 60 Stockholm, Sweden
> www.dice.se
>  
>  
> Corporate Registration Number: 556710-6520 
>  
>  
>  
>   
>