Re: [Threads-devel] Mutexes

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2006-03-02 07:28:00

David Abrahams schrieb:
> I think it's great to discuss these things, and we should probably
> pursue them.  That said, and I hate to be a killjoy, don't we need to
> focus on the library reimplementation and stabilization before we look
> at new design ideas?
>   
This might sound reasonable, but as I was trying to point out, there are 
some problems
in the current library. Altough what follows might seem like a small 
bug, I think it indeed
is part of a design problem.

Let me start. As I already pointed out I think the destructor of the 
mutex is wrong. You can
see this explicitely on windows, where the destructor is supposed to end 
the program when
the lock still is held by another thread:

    int res = 0;
    res = CloseHandle(mutex_cast(mutex));
    assert(res);

But this piece of code simply won't do what you should expect it to do. 
CloseHandle returns
_without_ error, even when the mutex is locked!

I tested with the following snippet on Win2k:

#include <windows.h>

HANDLE m;
HANDLE th;

DWORD WINAPI thread_main(LPVOID)
{
    WaitForSingleObject(m, INFINITE);
    while(true) {};
    return 0;
}

int main(int argc, char* argv[])
{
DWORD error;

    m = CreateMutex(NULL, FALSE, NULL);
    th = CreateThread(NULL,0,thread_main, NULL, 0, NULL);
    Sleep(1000);
    // At this point thread_main still holds the lock
    if (!CloseHandle(m)) {
        // ... but CloseHandle does not return with an error!!
        // and this is really bad, since it means we cannot
        // detect that the lock still is owned.
        error = GetLastError();
    }
    return 0;
}

This means, despite the fact that I do not like to see that the program 
is expected
to bomb out in case of the destoctor call when the precondition is not 
fullfilled,
on windows it will not even bomb out! Leaving behind a broken yet running
program. Even if one can show me how this "bug" could be easily cured, I 
think
we should aim on something more elegant than just bomb out.

Then I tried to dive deeper, and reached the belief that the problem 
should be
solved by rethinking the mutex interface from ground up.

Another point: Anthony is proposing (as I understood) to have a mutex 
without
a destructor. Hmm, how would one release the system mutex resource then?

BTW.: On possible cure would be:
    int res = 0;
    WaitForSingleObject(mutex_cast(mutex));
    res = CloseHandle(mutex_cast(mutex));
    assert(res);

But this 1) still is undocumented use of CloseHandle and
2) change semantics (doesn't it?)

Roland