RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately
david.holmes at oracle.com
Wed May 14 09:05:11 UTC 2014
On 14/05/2014 11:06 AM, Vitaly Davidovich wrote:
> In windows, you acquire a mutex by waiting on it using one of the wait
> functions, one of them employed in the code in question. If
> WaitForMultipleObjects succeeds and returns the index of the mutex,
> current thread has ownership now.
Yes I understand the basic mechanics :)
> It's also common to use multi wait functions where the event is a
> "cancelation token", e.g. manual reset event; this allows someone to
> cancel waiting on mutex acquisition and return from the wait function.
> Presumably that's the case here, but I'll let Aleksej confirm; just
> wanted to throw this out there in the meantime :).
Ah I see - yes cancellable lock acquisition would make sense.
> Sent from my phone
> On May 13, 2014 6:46 PM, "David Holmes" <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
> Hi Aleksej,
> Thanks for the doc references regarding abandonment.
> Let me rephrase my question. What is this logic trying to achieve by
> waiting on both a mutex and an event? Do we already own the mutex
> when this function is called?
> On 13/05/2014 11:19 PM, Aleksej Efimov wrote:
> The Windows has a different terminology for mutex objects (much
> from the POSIX one). This one link gave me some understanding of
> it .
> Here is the MSDN  description of what "abandoned mutex" is:
> " If a thread terminates without releasing its ownership of a mutex
> object, the mutex object is considered to be abandoned. A
> waiting thread
> can acquire ownership of an abandoned mutex object, but the wait
> function will return*WAIT_ABANDONED*to indicate that the mutex
> object is
> abandoned. An abandoned mutex object indicates that an error has
> occurred and that any shared resource being protected by the mutex
> object is in an undefined state. If the thread proceeds as
> though the
> mutex object had not been abandoned, it is no longer considered
> abandoned after the thread releases its ownership. This restores
> behavior if a handle to the mutex object is subsequently
> specified in a
> wait function."
> What does it mean to wait on mutex and ownership of the mutex
> "Any thread with a handle to a mutex object can use one of thewait
> request ownership of the mutex object. If the mutex object is
> owned by
> another thread, the wait function blocks the requesting thread
> until the
> owning thread releases the mutex object using the*ReleaseMutex*
> How we can release mutex and wait on already owned mutex:
> " After a thread obtains ownership of a mutex, it can specify
> the same
> mutex in repeated calls to the wait-functions
> blocking its execution. This prevents a thread from deadlocking
> while waiting for a mutex that it already owns. To release its
> under such circumstances, the thread must call*ReleaseMutex*
> for each time that the mutex satisfied the conditions of a wait
> On 05/13/2014 04:00 PM, David Holmes wrote:
> I don't understand this one at all. What is an "abandoned
> mutex"? For
> that matter why does the code wait on a mutex and an event?
> Do we
> already own the mutex? If so what does it mean to wait on
> it? If not
> then how can we release it?
> On 13/05/2014 8:57 PM, Alan Bateman wrote:
> This is debugger's shared memory transport so cc'ing
> as that is there this code is maintained.
> Is there a test case or any outline of the conditions
> that cause this? I
> think that would be useful to understand the issue further.
> On 13/05/2014 11:46, Aleksej Efimov wrote:
> Can I have a review for 8032901 bug  fix .
> There is a possible
> case when 'WaitForMultipleObjects' function can
> return the
> WAIT_ABANDONED_0  error value.
> In such case it's better to release the mutex and
> return error value.
> This will prevent other threads to be blocked on
> abandoned mutex.
> Thank you,
More information about the core-libs-dev