Re: [boost] (no subject)

From: Victor A. Wagner, Jr. (vawjr_at_[hidden])
Date: 2002-05-19 16:31:43

At Sunday 2002/05/19 12:36, you wrote:
> > I don't understand how we get here.  T1 doesn't go "do work" unless HIS
> > lock is on the circuit breaker keeping it from being closed (and the
> > power being turned on)
>
>A thread can get preempted at any time, and another thread can start.
>In code, you're going to have to write something along the lines of
>this for a worker,
>
>1:  if(!switch_on)
>2:    add_my_padlock();
>
>and something like this for a person turning on the power,
>
>3:  if(!switch_has_padlocks())
>4:    turn_switch_on();
>

Of course, that's the whole point

>I'll do it with just two threads to simplify.
>
>The switch is off.
>
>T1, executing the first snippet looks at the switch to see if its
>on (line 1). T1 is suspended by the scheduler and T2 starts
>
>T2, executing the second snippet looks at the switch to see if
>there are padlocks on it (line 3).
>
>T2, sees no locks yet so it turns the power on (line 4).
>
>T1, resumes execution (line 2) - it has already checked the switch
>to see if its ok to put a padlock there. So it goes ahead and adds
>its lock thinking the power is off. The power was on.

given that you canNOT add a padlock unless the power is off...it's 
physically impossible.
BTW, thanks for the instruction on how this must work, but I was writing 
(and guaranteeing concurrency safety back in 1973) and ensuring that new 
computers we built didn't remove the possibility of writing such "locks".

>Clearly, this is a race condition. The right way to avoid it is
>to serialize access to switch. It may not always happen, it depends on
>how the threads are scheduled (and its out of the hands of the
>programmer), but it can happen and this will lead to a very serious
>problem.
>
> > Filling all of memory with zeros is dangerous also
> > setting your priority to as high as possible then doing while(1); is
> > dangerous SO???  At least semaphores have utility (which outweighs their
> > hazard, IMO). One can easily wrap a mutex around a semaphore, the other
> > way is somewhat more problematic
>
>The danger in this case that I'm talking about is that using only
>a semaphore leads to a race condition and because of that, it is the
>wrong way to approach this problem. Its not so much a matter of
>what feeling safe and taking the bet that the race condition doesn't
>occur, its a matter of what is correctness by choosing a method that
>doesn't contain flaws like a race conditon. Wrapping a mutex around
>the semaphore may work, but why even keep the semaphore? It doesn't
>have a purpose anymore if you add the mutex.

because there are OTHER cases where you need a semaphore... you canNOT 
access a mutex other than from the thread that "owns" it.

>- 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"