|
Boost : |
From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-02-18 08:12:06
That's because lock promotion wasn't fully implemented in the original
version of the library and was (apparently incompletely) removed from
the version in cvs.
For what it's worth, I have a version in which I have implemented lock
promotion/demotion and made a number of other changes. Perhaps I
should add this to the thread_dev branch of CVS to make it available
for others to look at, and if any of the changes prove undesirable
they can be backed out?
As a warning, I should mention that I corresponded privately with
William Kempf quite a long time ago about lock promotion and demotion,
and he said:
> That's a hot topic. I'm not sure the feature is really that useful
since
> it will provide only a minor performance boost in comparison to
simply
> unlocking and relocking with the new type. I'm hesitant to even
look into
> this, since nearly every implementation that's been posted to the
various
> groups has been proven to be incorrect, illustrating that this is a
> difficult thing to implement correctly (and once you do, is there
any real
> performance increase?).
Having said that, I've been using all my changes for quite some time
without problems.
Mike
"Vladimir Prus" <ghost_at_[hidden]> wrote in message
news:200402181516.08991.ghost_at_cs.msu.su...
>
> Hello,
> I was looking at rw_lock implementation in the thread_dev branch and
see that
> member variable
>
> m_num_waiting_promotion
>
> is only set in constructor to '0' and then once tested for equality
with 1.
> So, looks like it has no effect at all? Did I miss anything?
>
> Note: I'm not yet planning to use rw_lock, I'm just looking at
implementation.
>
> - Volodya
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk