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
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
