Boost logo

Threads-Devel :

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.


Threads-Devel list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk