Re: [Threads-devel] fast mutexes

From: Milutin Jovanovic (milutin.jovanovic_at_[hidden])
Date: 2006-08-04 15:56:54

Thanx for the answer.

>> Implementation wise, in the worst case it would have the same 
>> implementation
>> as mutex. But on Windows at least it would be faster then named 
>> mutexes...
>
> Hmm.. do you have numbers?

I am sorry, but I do not. I am driven by some comparisons that I did some 7 
years ago, and I allowed myself an assumption that the same still holds 
true. In those times I found that CRITICALSECTION was about 40% faster then 
a Mutex (if my memory holds).

>> It would not have the full
>> functionality of the mutex, but in many cases that is not required.
>
> Which functionality do you mean? You can't simply change semantics
> without harm.

I was not clear before. I never proposed getting rid of existing mutex, 
since it is impossible to have waits with a timeout on a CRITICALSECTION. I 
rather meant having an addition type of mutex, used only for certain kind of 
locking, with a possible speed boost.

If boost had room for int_fast_t to facilitate faster code, I thought having 
a fast_mutex was not completely out of the question. Actually, if boost 
internally has a need for lightweight_mutex, you surely can see that other 
have the same need as well.

BTW, if the new implementation uses the lighter (CRITICALSECTION or similar) 
implementation... Then my point is mute. Although I am curious to see how 
will you achieve timed waits.

Regards,
Milutin Jovanovic.