[Spread-users] Question about thread-safety

[Theo E. Schlossnagle]

John Schultz wrote:
> Theo E. Schlossnagle wrote:
> 
>> John Schultz wrote:
> Are we talking about the same problems? The race condition I've mainly 
> been talking about in this discussion involves using file descriptors 
> (in particular opening/closing) in multiple threads inside a single 
> process (let's ignore Linux's perverted notion of a thread: a light 
> weight process). I pointed out that Spread's user library summarily 
> closes its file descriptors upon receiving errors, which makes it very 
> difficult for the user to ensure that the mailbox "it is using" is the 
> mailbox "it thinks it is using" in threaded applications. I think the 
> Spread library should insulate the user from this problem.
> 
> James Rauser brought up the multiprocess/fork problem that I hadn't 
> considered at all until my previous email.

Umm... <sheepish grin>... I guess not.  But a context would solve that too!!!

> 
> I agree that the Spread library should return a reference to a
> context that it uses to implement its functionality instead of a file
> descriptor.
> 
> However, I would argue that the library should continue to hide the real 
> context in an internal table and rather than return a pointer, it should 
> return an "eternally unique" integer handle to the internal context. 
> This would allow any SP call on a reclaimed handle to fail nicely 
> (INVALID_HANDLE) instead of potentially crashing due to invalid use of 
> an already reclaimed context pointer.
> 
> This would allow the user to reclaim the context at any point in time: 
> they wouldn't have to ensure that all threads that might use that 
> context have stopped using the context before reclaiming it. If a SP 
> call returns an INVALID_HANDLE error they can assume that another thread 
> reclaimed/closed the context.
> 
> Of course, the drawback to this approach is a single globally 
> synchronized hashtable lookup for each SP call. IMO, this additional 
> overhead is dwarfed by the system IO the Spread library does and would 
> have no impact on performance.

If you hand back a context pointer (still opaque), you solve all that.  You 
don't let the user see inside the context at all (it is effectively an 
"externally unique" integer handle).  This is how many other library 
interfaces work.  Then, the full contect implementation (inside the library) 
can have whatever synchronization crutches it need stored inside the context.

-- 
Theo Schlossnagle
Principal Consultant
OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
Phone:  +1 410 872 4910 x201     Fax:  +1 410 872 4911
1024D/82844984/95FD 30F1 489E 4613 F22E  491A 7E88 364C 8284 4984
2047R/33131B65/71 F7 95 64 49 76 5D BA  3D 90 B9 9F BE 27 24 E7