[Spread-users] Question about thread-safety

[John Schultz]

On Wed, 18 Jun 2003, Theo E. Schlossnagle wrote:

> John Schultz wrote:
> >
> > Yes, the safety can be completely handled within the library: by
> > internally employing a method such as my table method.
>
> I wasn't claiming that your method couldn't do that.  You implied that using
> context's didn't allow for that.  Which is wrong.

I disagree. You are forcing the user to perform external synchronization,
which by definition is external to the library. I was stating that my
method lets the user skate on this issue by performing safe internal
garbage collection for the user.

> If you are attacking the argument that you can't have two threads free the
> same context safely -- then you are right.  But don't use C.  Two threads can
> go free the same malloc()ed segment either.  But standard thread-aware
> programming doesn't put you in a pinch like that.

I was saying that with very little additional effort in the library we can
free the user from having to worry about synchronizing the reclamation of
SP_context refs, which is a nice little perk.

> Of course.  SP_disconnection _would not_ free the context if contexts were
> used.  An explicit call to SP_context_destroy() would be called.  And yes, one
> and onlyone of the threads can call that context_destroy function.  That is
> not a flaw at all... If it were, then malloc()ing string and then complaining
> that you can't free it multiple times in different threads would be valid...
> That's just part of threaded programming.

I'm not claiming the normal way is flawed. I'm saying my alternative
method makes it easier on the user to be correct. They can "free"
(reclaim) the SP context multiple times and it's AOK -- because only the
first reclaim call actually does the reclamation and all subsequent
reclaims will fail with an INVALID_HANDLE error.

> You said that the opaque integer reference is used in libraries.  I'd be
> interested at looking at a completed product that uses such a method and
> compare it against other libraries that use a standard context set up (like
> OpenSSL, Sybase, MySQL, Postgres, etc.)

I wouldn't use this method in every application/library.  For example,
there is no reason to hide an in-memory data structure (e.g. - a linked
list) behind an opaque integer handle.  However, because Spread performs
system IO and has to protect its file descriptors carefully (the race
condition that started all of this), the Spread user library is a good
candidate for this treatment.

I intend to eventually implement this in a new Spread user library.  At
that time we can compare the performance of the new library vs. the old
and see if there is any noticeable overhead.

---
John Schultz
Co-Founder, Lead Engineer
D-Fusion, Inc. (http://www.d-fusion.net)
Phn: 443 838 2200 Fax: