Boost logo

Threads-Devel :

Subject: Re: [Threads-devel] an obscurity in void basic_timed_mutex::clear_waiting_and_try_lock(long& old_count)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-02-12 02:24:13

Le 11/02/13 12:13, Stefan Djukic a écrit :
> Hi guys,
> Recently, I had to make a decision about which synchro mechanism to
> use for a new project for which the target OS should be Windows and/or
> Solaris/Linux. So, I've finally decided to dig deeper into the Boost
> thread lib, and have started with the most fundamental one, the mutex
> (for Windows, of course). At first it was very hard to crack it, but
> soon enough, the things have started to get their logic. Now, the
> logic behind it seems pretty much ok, with one small exception. No
> matter how hard I've tried to understand it, it keeps to be elusive.
> I've tried, also, to google about it, but surprisingly not much was
> posted on the subject (or I was looking on the wrong side).
> So, I cannot understand what is the point of using the old_count as
> the input value in void
> basic_timed_mutex::clear_waiting_and_try_lock(long& old_count). At
> that point, the /old_count in all threads waiting on mutex would be
> less than the current value of active_count/ (the way it is done
> in mark_waiting_and_try_lock()).
> In the first iteration of clear_waiting_and_try_lock() the value of
> the old_count will always be compared to active_count, and after that,
> as it would be different, use its current value for the next
> iteration. So, what's the point of the first iteration? On the other
> hand, it seems planned very carefully to do exactly that, but I cannot
> see why. Why not instead of the line old_count&=~lock_flag_value; set
> the old_count to zero, or even better
> to: old_count=active_count&~lock_flag_value;, that way, at least, one
> thread could obtain the lock in the first iteration. It also seems,
> that the first versions of mutex (prior to rev 45119), would not have
> this first extra iteration.
> Anyway, I do not see much harm in the way it's done, but not much
> benefit, either.

I don't know well the windows implementation. I don't have too much time
now to study the code. I will come back to this issue as soon as possible.

For the time been, please, could you try to patch with some of the ideas
you have and see if the complete regression tests are working yet. If it
is the case a performance comparison will be useful. If not this will
give you some hints on why the things are done currently.


Threads-Devel list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at