RE: Proposal for boosted Symb device support

[Jeff Hill <johill@lanl.gov>]

> I agree that intLock/intUnlock is dangerous in the situations you
> describe. On the other hand: what if you have some external SW package
> that you cannot or don't want to modify, and that installs an interrupt
> handler that updates your global variable. Then you will have a problem
> with the semaphore solution because your SW package does not know
> anything about it. I think the Symb device support should be able to
> handle such a situation safely.
> 
> The argument about affecting the whole system (intLock) vs. small
> components (mutex semaphore) is a good one, but mind that we are talking
> about a _globally_ visible object that _any_ instance in the system can
> modify, even the user from the shell. I see no other way to protect such
> a variable globally but by a global mechanism.

Sorry to nit pick, I obviously was not thinking about your unique situation. I Agree that 
if the user is changing the variable from the shell or any other task level program 
that does not use the mutex semaphore then at least taskLock() will be required, 
and that if ISRs are involved then intLock() will be required to solve both problems. 
If multiple processors and also interrupts are involved then a global solution may 
prove to be elusive. I still worry that an exception might occur while intLock() is applied,
but perhaps this risk is worth taking in order to allow unconstrained synchronized 
access to globally known variables.

Jeff