Bugzilla – Bug 686
globus_mutex_lock() behaves differently on Unix -vs- Win32
Last modified: 2007-09-19 11:21:52
You need to log in 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 covers... 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. Joe
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. Joe
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 from us.