Re: [boost] Boost.Threads Locking Delima

From: Victor A. Wagner, Jr. (vawjr_at_[hidden])
Date: 2002-05-19 00:55:04

At Saturday 2002/05/18 12:55, you wrote:

> > To use an analogy that's been in use for decades to save human lives:
> > At large construction sites where various electrical work  will be going
> > on, there is a shutoff which can be locked _open_ simply by putting a
> > common padlock on it.  The "hole" for the padlock to secure is large
> > enough
> > for many locks.  When an electrician comes to work and needs the power
> > killed, s/he simply adds his/her personal lock.  When done, one removes
> > one's own lock and leaves.  The power cannot be restored until ALL the
> > locks are gone.
> > Certainly this model can be explained even to a newbie (especially if
> > they've ever managed to be on the receiving end of an electrical shock)
> > and
> > is reliable, and considered foolproof enough to have lives depend on
> > it.  Modelling it for use in multi-threading/tasking seems natural to
> > me.
>
>I think this example is good, but the way you describe it makes things
>easy to misunderstand. You describe the workers in this scenario (threads)
>as all owning thier own lock, and coming along an placing it on the power
>supply (resource). It makes it seem as though the threads are in charge of
>the locks and not the resource. However, the real point of control is at
>the resource - that must be synchronized (all the workers cannot put
>locks on and off simultaneously for this to work - there would be a race
>condition to quickly lock your padlock before another guy so you don't
>get electrocuted).

I guess you've never seen one.  There is NO hazard of electrocution while 
attempting to put your lock on.. you're not in the hazard area.
And it doesn't matter who locks it "first" you both then get to go do your 
work.

>The way this would normally be modeled in a real program would be for the
>resource to own a 'lock' (I use the term lock here as a general
>synchronization control, semaphore or mutex with a count in the resource,
>a latch, or whatever - its not important, you can implement the locking
>mechanism in a number of ways). This 'lock' would be used by the threads
>that need to be coordinated. The workers really don't own a 'lock', thier
>padlock is more of a token. They come to the resource and place thier
>token (padlock) in it, the resource controls access to it - the resource
>controls the lock, not the threads. (I'll use code to explain this more
>clearly below, I'm a programmer - its easier to communicate that way :)

I wasn't suggesting an implementation.  Simply some analogous problem 
(access to some resource that prevents some other from abusing the resource).

> > Note this _may_ imply a requirement that more than one thread may need
> > access to the same "hole" and may necessitate a _real_ semaphore (i.e.
> > signalable by a thread other than it's "owner") rather than "thread safe"
> > mutexes.
>
>I think a semaphore would seem like a good choice at first just because it
>keeps a count associated with it, but you would still need another
>synchronization control to ensure that thigns work out. A semaphore would
>work better alone if you wanted to say something like no more than 5 guys
>can work here at any time.

I'm in favor of semaphores, but my review of the message history shows that 
some felt they were "too dangerous" (a shame, IMO).

> > My above analogy to locking the electrical power off _may_ show that you
> > not only need to transfer locks to functions, but, I believe, that you
> > may need to either share or transfer them to other
> > threads/processes/tasks/whatever.  The analogy for transfer is, of
> > course, handing the key to _your_ lock to someone else
>
>If you approach the problem from a different angle this is not needed
>at all. I think most problems can be dealt with like this. In my
>expirience, if you find yourself in the situation where you begin to need
>things as complicated as a sharing & transfer locks then its an indication
>you may need to change your design.

mayhaps, yet we transfer "ownership" of other things (logically, as 
in  "who calls delete on this pointer?", and automagically as int 
auto_ptr<>).  I submit that transferring "ownership" of a resource is no 
different.

>// I'm typing this in, so there could be typo's & I'm using ZThreads
>// constructs since I am most familiar with those - but I think its
>// clear enough what is happening even if you aren't familiar with that
>// library.
>
>class PowerSupply {
>
>   Mutex lock;
>   int count;
>
>public:
>
>   PowerSupply() : count(0) { }
>
>   void addPadlock() {
>
>     Guard<Mutex> guard(lock);
>     count++;
>
>   }
>
>   void removePadlock() {
>
>     Guard<Mutex> guard(lock);
>     count--;
>
>   }
>
>   void powerOn() {
>
>     Guard<Mutex> guard(lock);
>     if(count)
>       throw please_dont_eletrocute_someone_today;
>
>   }
>
>};
>
>With something along these lines, you don't need to transfer locks. You
>have to place the focus of your synchronization in the correct place -
>on the thing you want to control access to, not on the things that need
>to be controlled. Trying to approach these kinds of problems in the later
>way is only going to become more complicated and more error prone. I'm
>not sure I see the benefit to doing something that way. (you'll still need
>a single point of control to manage a set of locks correctly anyway,
>except now since the resource doesn't control its own acces it is much
>more difficult to deal with).

I read all the words, and I don't understand what you're trying to say.

>- Eric
>http://www.cse.buffalo.edu/~crahen
>
>_______________________________________________
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Victor A. Wagner Jr.      http://rudbek.com
PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A
PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93
The five most dangerous words in the English language:
               "There oughta be a law"