Re: Why are Boost thread mutexes so slow compared to Pthreads?

Juha Nieminen wrote:
Alexander Terekhov wrote:
There are basically four approaches here:

1. Don't let unlock() happen automatically for unexpected throws
(with/from unexpected reasons/places) and let eventual deadlock (with
lack of higher level heartbeat watchdog, something like EOWNERDEAD or
ENOTRECOVERABLE returned on subsequent lock()) to expose corruption.
(Practical approach.)

2. Pretend that unexpected throws just can't happen under the current
C++ language. (Utopia.)

3. Pretend that unexpected throws must call abort() at throw points. (In
general, utopia as well given failed attempts to get rid of idiotic and
unnecessary catch(...) all across the current C++ language and commonly
known anti-patterns using idiotic and unnecessary catch(...).)

4. Dream of the C++ language really ensuring that unexpected throws just
can't happen and hence there is no problem at all with automatic
unlock(). (Proper Nirvana.)

You forgot the fifth approach:

5. Expect that exceptions might be thrown at any point and make it so
that the function will release the lock if that happens.

A thrown exception may not be a fatal error per se, and it may well be
an exception handling of which is not a duty of this function at all
(eg. out of memory exceptions). There's no reason why this function
cannot simply *work correctly* regardless of whether something throws an
exception in the middle of it or not.

That depends on your definition of "work correctly".

If you get an out of memory exception part way through an update you are
in big trouble and a scoped lock can cause more harm than good.

In my experience, most errors that can occur inside a lock have to be
fixed before the lock is released. Maybe it's just my style, but I
typically use a lock to make a sequence of actions atomic. If one of
those actions fails, I want to roll back the change. To do this I do
use a scoped lock, but the destructor action is to verify the
transaction has been committed. What happens if the transaction has not
been committed depends on the situation. If a roll back is possible,
then roll back, release lock and re-throw is OK. If not, an abort may
may be in order.

For the function to work correctly, if it locks a mutex, it has to
unlock it before exiting. You have two choices for this:

That depends on the severity of the error, you can't generalise.

1) Enclose everything in the function inside a 'try' block, catch
everything, and in the 'catch' block release the lock and rethrow.

2) Use a scoped lock, which achieves the exact same thing with less
writing, in a less error-prone way.

The advantage of method 2 is that it will also work with all explicit
function exits without having to manually unlock before each.

I still think early returns should be handled differently from
exceptions. I'm very cautious of automatically unlocking on an early
return. If the case for the early return has been correctly thought
through, there's no good reason not to include an unlock in that
execution path.

It's too easy to use a scoped lock as a band-aid for a poor design.
They do have their place, but the aren't the silver bullet some people
make them out to be.

--
Ian Collins
.

Relevant Pages

  • Re: Why are Boost thread mutexes so slow compared to Pthreads?
    ... Don't let unlock() happen automatically for unexpected throws ... (with/from unexpected reasons/places) ... ENOTRECOVERABLE returned on subsequent lock()) to expose corruption. ... A thrown exception may not be a fatal error per se, ...
    (comp.programming.threads)
  • Re: Compiling C++ modules
    ... So let me get this straight - We lock something, ... an exception because something corrupted the lock. ... Most often, the cause of the exception is not random corruption, but an error and you want to unlock the lock. ... C++ helps you get it right without writing tons of boilerplate code: ...
    (Linux-Kernel)
  • Re: Performance issue of ASP .NET
    ... If you lock a resource, do some steps, get an exception while the resource is locked, and then exit to an exception handler you will not unlock the resource. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: CMutex /CEvent (multiple threads)
    ... deals with exception detection. ...  If your function does not handle an exception in Java, ... designer did not understand what a Mutex was and that the notion that Lock could return ... ...roll back transaction ...
    (microsoft.public.vc.mfc)
  • =?iso-8859-1?q?D=E9j=E0_vu_bug:_The_Matrix_uses_the_.NET_Framework!?=
    ... encounters a .NET Framework bug. ... intermittent lock leak that was not the kind you find in text book. ... exception is thrown in either A, ... private static void Throw ...
    (microsoft.public.dotnet.framework)