[Spread-users] Question about thread-safety

Theo E. Schlossnagle jesus at omniti.com
Wed Jun 18 14:17:43 EDT 2003


John Schultz wrote:
> On Wed, 18 Jun 2003, Theo E. Schlossnagle wrote:
> 
> 
>>John Schultz wrote:
>>
>>
>>>Your method would still require that the user ensure that all threads
>>>that might use the context, stop using the context before it is reclaimed.
>>
>>No.  That safety can be completely handled within the library.
> 
> 
> 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.

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.

> In your setup SP_context is a pointer to some opaque context.  In my setup
> SP_context is an integer handle to some internal context; this makes my
> casts to and from void* dubious, but let that slide for now.

Honestly there is very little difference here.

> In the code, all the threads call SP_disconnect (reclaim sp_ref) upon
> detecting an error. This code is not valid under your setup, but it is
> valid under mine.  The difference comes in the way the threads reclaim
> sp_ref's context under our setups.


> Under your setup, when an error is detected, ONE AND ONLY ONE thread can
> ACTUALLY reclaim sp_ref's resources and it has to be the LAST thread to
> use sp_ref.

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.

> At some point in time your contexts have to be freed or you have a memory
> leak.

Just like strings.  Yes.

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.)


-- 
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





More information about the Spread-users mailing list