Subject: Re: [Threads-devel] v2/shared_mutex bitmask refactoring
From: Fredrik Orderud (forderud_at_[hidden])
Date: 2013-04-14 14:19:17
Forwarding the response from Howard Hinnant to the mailing list.
On Apr 9, 2013, at 1:25 PM, Fredrik Orderud <forderud_at_[hidden]>
Vicente J. Botet Escriba and I have recently discussed your usage of
"bitmask" manipulation in boost::thread v2/shared_mutex &
upgrade_mutex. In particular, I've proposed to replace the "bitmask"
manipulaiton with equivalent "bitfields" for improved readability. You
can read through the discussion through the link below.
Could you please give us your thoughts on the discusion? Are there
e.g. any specific reason for not using bitfields?
Thanks in advance,
Hi Fredrik, Vicente,
This looks like a good idea to me (putting in bitfields). There may
be places where I'm reading or writing more than one bitfield at a
time, so watch out for that. It has been so long since I wrote this
code, I don't remember for sure. Indeed, if I'm doing that, that may
have been the motivation for not using bitfields. However I imagine
if there is any performance lost, it could be gained back by unioning
the bitfield rep with the unsigned rep.
I can see that the two of you are doing a very careful review of this
complicated code. That is much appreciated. I don't currently have
the time for such a review, even though it is my own code.
I suspect that Howard Hinnant prefered a fair solution.
After more deep insight I'm wondering if write_entered_ is not used to
ensure priority for writers. Note that write_entered_ doesn't mean that
the mutex is in exclusive mode but that some one has requested to be
in. The mutex is in exclusive mode when write_entered_ and n_readers_==0.
My intent was to use a fair algorithm.
Contention for gate1 should be completely fair. However once a writer
gets past gate1, then he is prioritized as the next owner. Same is
true of a reader though: Once past gate1 a reader is also the next