Boost logo

Boost Users :

Subject: [Boost-users] [Thread] order of shared_lock and unique_lock acquisitions
From: Roland Bock (rbock_at_[hidden])
Date: 2009-01-09 07:02:36


Hi,

I am trying to use shared_lock and unique_lock on a shared_mutex to
allow read-functions to access a certain resource in parallel, but write
functions use the resource exclusively.

Is there a way to determine the order in which the (shared) locks are
acquired? I tried testing with the attached program and got rather weird
and (seemingly) non-deterministic results.

In the test program (see attachment), I start 9 threads of readers(r)
and writers(w). Before doing anything else, the sleep and wake up in groups.

rrww
rr
w
rr

There is one second delay between the groups I would expect to see them
working in this order:

rr
w
w

rr

w

rr

The first group could be scrambled of course since they race for the
lock. But at least I would expect the order of groups to be maintained.

I get quite different results, though, and the results differ from run
to run. The weirdest result I saw until now is attached.

rr

rrr (these do not start before the first group is finished)

w
w
w (the last writer is handled in second position btw)

r

This I do not understand at all. The readers are using the shared mutex.
Why is the second group waiting for the first to be finished? And how
can the last writer be handled in second place?

I am at a total loss here...

System information:
-------------------
boost-1.36
Ubuntu-8.04
gcc-4.2.4
Intel Quad Core processor

Thanks in advance,

Roland

reader(0) at 0 sleeping 5
reader(1) at 0 sleeping 5
writer(2) at 0 sleeping 5
writer(3) at 0 sleeping 5
reader(4) at 0 sleeping 6
reader(5) at 0 sleeping 6
writer(6) at 0 sleeping 7
reader(7) at 0 sleeping 8
reader(8) at 0 sleeping 8
                             reader(0) at 5 trying to acquire lock
reader(0) at 5 got lock
                             reader(1) at 5 trying to acquire lock
reader(1) at 5 got lock
                             writer(2) at 5 trying to acquire lock
                             writer(3) at 5 trying to acquire lock
                             reader(4) at 6 trying to acquire lock
                             reader(5) at 6 trying to acquire lock
                             writer(6) at 7 trying to acquire lock
                             reader(7) at 8 trying to acquire lock
                             reader(8) at 8 trying to acquire lock
                                                         reader(0) at 10 finished
                                                         reader(1) at 10 finished
reader(4) at 10 got lock
reader(5) at 10 got lock
reader(7) at 10 got lock
                                                         reader(4) at 15 finished
                                                         reader(5) at 15 finished
                                                         reader(7) at 15 finished
writer(3) at 15 got lock
                                                         writer(3) at 20 finished
writer(6) at 20 got lock
                                                         writer(6) at 25 finished
writer(2) at 25 got lock
                                                         writer(2) at 30 finished
reader(8) at 30 got lock
                                                         reader(8) at 35 finished



Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net