|
|
Threads-Devel : |
Subject: [Threads-devel] an obscurity in void basic_timed_mutex::clear_waiting_and_try_lock(long& old_count)
From: Stefan Djukic (stefan.djukic_at_[hidden])
Date: 2013-02-11 06:13:40
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.
Sorry for the annoyance.
Regards,
Stefan Djukic