oz_(un)protect() API unsafe

[Raphael Collet]

Denys Duchier wrote:
> 
> I am thinking in terms of a little itch I am scratching involving pthreads.  It
> will usually be the case that tasks delegated to pthreads will need to hold on
> to some Oz data structure, if only to have a way to return a result or indicate
> termination etc...  They will therefore need to OZ_protect it on initiation and
> OZ_unprotect it on termination.  If it turns out that 2 tasks need to hold on to
> the same Oz data structure, the first one to terminate will OZ_unprotect the
> data and that data may well be garbage collected before the second task
> terminates.

Ok, now I see.  The situation is problematic only in the case where both 
tasks store the reference in the same location.  It means two pthreads 
explicitly sharing memory.  If references are stored in different 
locations, everything works fine.

The second call to oz_protect() will violate the assertion "!find(el)" 
at line 115 in g-collect.cc.  But the real issue would be the double call to

	oz_gCollectTerm(*ret->elem,*ret->elem);

with identical locations.  (Isn't oz_gCollectTerm() robust in such a case?)

> The fix is simply to add a counter to each protected data: the counter is
> incremented by oz_protect and decremented by oz_unprotect.  You would only really
> unlink the data from the protected list if the counter reaches 0.

Sounds fine to me.

Cheers,
raph