[boost] scoped_lock performance

From: Christophe Meessen (christophe_at_[hidden])
Date: 2003-10-20 05:55:44

Hello,

thanks for pointing me out the existence of the lightweight mutexes. Its 
a very impressive piece of work. Thanks also for the comments on 
"overkill". This confirms the need for mutex. But then it is very 
important that we have an efficient one. It's sad that the lightweight 
mutex is not advertized in the boost documentation.. We really need 
something like that because it is not covered by the thread scoped_lock.

Beside I also find it useless to write scoped_ in front since there is 
nothing else than scoped locks and they always should be scoped in C++.

Beside, there is a problem in the thread package with the different kind 
of mutexes. The API gives the impression that to perform a try_lock we 
need a try_mutex and to performe a timed_lock we need a timed_mutex. In 
some not so infrequent cases we may want to do a try_lock,  timed_lock 
and lock on the same kind of mutex object.

This is why I think that the difference between mutex, try_mutex and 
timed_mutex should be removed from the API. There should only be one 
mutex type. And there should thus also be only one type of lock object 
with the methods lock(),unlock(), try_lock(), timed_lock() and 
is_locked(). The default initial locking state should also be false in 
all cases.

This implies significant effort in the coding to provide the most 
efficient implementation.  But this is a distinct problem.

PS: I saw that the lightweight mutex implementation for WIN32 uses DLL 
calls to the CriticalSection functions. Wouldn't this introduce 
undesirable performance overhead ?

-- 
Bien cordialement,
Ch. Meessen