Bugzilla – Bug 686
globus_mutex_lock() behaves differently on Unix -vs- Win32
Last modified: 2007-09-19 11:21:52
You need to
before you can comment on or make changes to this bug.
We have run into the following problem when working on getting a Condor-G
running on Win32 using the Globus 2.x Win32 libraries:
the problem we saw w/ the globus win32 alpha libraries was if you created a
mutex X with globus_mutex_lock() in thread A and released it
with globus_mutex_unlock() in thread B, nobody could grab mutex X again (in
either thread A or thread B) --- it was as if the code never "noticed" that
mutex X was every released.
i admit grabbing a lock in thread A and releasing it in thread B is a little
uncommon. but this code *does work* on Unix. question: anywhere in the globus
toolkit proper are locks created in one thread and released in another? if
not, then we could easily work around this issue by using a Win32 critical
section in our code instead of a globus_mutex_lock(). but if some parts of the
globus toolkit also use locks this way, things will be broken under the
thanks in advance for your feedback...
-Todd Tannenbaum, Condor Project, Univ of Wisconsin
I am pretty sure we wouldn't use locks in the way you mention. However, I do
agree that it is a bug that should be fixed. I cannot promise anything on time
though. The Win32 port is still pretty low priority.
Looks like this is a windows semantics issue. In order to provide identical
functionality, we will have to reimplement our mutex abstractions with
semaphores instead of win32 mutexes.
Again, I have no clue when we will get to this.
Closing this, as we're not working on C GSI on Windows, just java. Univa's
release plans for windows C GSI are unclear, but don't involve funding/effort