[Pvfs2-developers] Trove patches

[Phil Carns]

>>So its an awefully expensive way to show the developer  
>>that he has bugs in his code
> 
> I doubt that it is so expensive. 
> That does not mean the developer has a bug in his code. He can first check if 
> the op is completed if not he calls test, however this thread gets 
> interrupted before obtaining the mutex and testcontext gets the mutex and 
> removes the operation. So the test fails with a segfault. 

Whether this is a developer bug or not depends on your interpretation of 
the interface semantics.  I don't think it is safe to mix testcontext() 
and test() calls in two different threads (for the same context anyway, 
see below) unless you do something to make sure that they are 
serialized.  They just are not compatible from an API point of view 
regardless of the implementation.  In your scenario for example, even if 
the IDs were made safer, what should the test() call return for its 
status?  The state of the operation is already gone, so you can't 
distinguish between the caller giving you a bogus ID and the caller 
giving you the ID of something that recently completed.  The thread that 
called test() assuming that the operation would be there will probably 
be confused by the result either way.

This issue isn't really unique to trove.  For example, suppose you have 
two threads that call poll().  One checks a single socket, the other 
checks a whole list of sockets including the same one that the first 
thread is checking.  What should happen when there is an event on the 
shared socket?  I don't know if POSIX defines what will happen here, but 
even if it does it is still bad practice for the application.

Also remember that the Trove interface has contexts that you can use as 
well to partition off sets of operations.  If you have a set of 
operations that you really don't want thread X to find when doing 
testcontext(), then open up a new context and post them there.  This 
mixture of testcontext() and test() are only a problem if they both hit 
the same context.  You could have two threads working in independent 
contexts without any conflicts.

-Phil