Still, if you (as somebody else suggested) wait on a ManualResetEvent or
event Monitor.Wait(onSomeObject) with timeout you don't need the sleeps and
the _stop thing, just:
for ( ; ; )
{
SePinState(on);
if (!stopEvent_.Wait(TimeSpan.FromMilliseconds(_onIntervalMs), false))
{
break;
}
SetPinState(off);
}
and your stop would look like:
void Stop()
{
stopEvent_.Set();
if (!thread_.Join(someTimeout))
{
// the MF should have died
thread.Abort(); // is cool here
}
}
Doing this, you're stopping ASAP, not after whatever timeout you have which
your thread is forced to sleep.
Cheers
On Fri, Mar 28, 2008 at 6:07 PM, Fabian Schmied <[EMAIL PROTECTED]>
wrote:
> > The code in the 'Go' method of Blinker is...
> >
> > public void Go ( )
> > {
> > _stop = false;
> > while ( !_stop )
> > {
> > SetPinState(on);
> > Thread.Sleep ( TimeSpan.FromMilliseconds ( _onIntervalMs
> > ) );
> > SetPinState(off);
> > Thread.Sleep ( TimeSpan.FromMilliseconds (
> > _offIntervalMs ) );
> > }
> > }
> >
> > public void Stop ()
> > {
> > _stop = true;
> >
> > }
>
> Don't forget that for this to work reliably, _stop must be declared
> "volatile". Either that or you must lock a synchronization object
> while accessing the _stop variable.
> (You cannot reliably access non-volatile state that is shared across
> different threads without locking.)
>
> Fabian
>
> ===================================
> This list is hosted by DevelopMentor(R) http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
>
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
