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.