Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-09-07 11:24:33


--- In boost_at_[hidden], "Bill Wade" <bill.wade_at_s...> wrote:
> > From: William Kempf [mailto:sirwillard_at_m...]
>
> > Uhmmm... I'd have to see a concrete example. Other than a slight
> > performance hit I can think of no reason why the locks must
overlap
> > this way.
>
> Consider single-linked list traversal. To move from node A (which
is
> currently locked) to *A.next you need to get a lock to *A.next and
then
> release your A lock. Compared to locking the entire list, this
allows
> essentially one processor per node rather than one processor per
list.

A corner case indeed! It's very rarely a good idea to use node level
locking here. The granularity is much too small and will lead to
very poor performance. Not to mention the complexity of transactual
uses.

In any event, I'm not sure this is a valid example any way. You
don't have to gain the lock for *A.next before releasing the lock on
A. A race condition might occur, where some other thread links in a
node between A and *A.next, but rarely will such a condition matter.
Deletion of nodes might be one such case, but such an operation
should really be done with a lock at the list level, not the node
level. I'm sure any other case you can come up with where the race
condition is important would also be a case where the granularity is
too small any way.

Bill Kempf


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk