AutoResetEvent vs. boolean to stop a thread

Question

I have an object in a worker thread, which I can instruct to stop running. I can implement this using a bool or an AutoResetEvent:

boolean:

private volatile bool _isRunning;

public void Run() {
    while (_isRunning)
    {
        doWork();
        Thread.Sleep(1000);
    }
}

AutoResetEvent:

private AutoResetEvent _stop;

public void Run() {
    do {
        doWork();
    } while (!_stop.WaitOne(1000));
}

The Stop() method would then set _isRunning to false, or call _stop.Set().

Apart from that the solution with AutoResetEvent may stop a little faster, is there any difference between these method? Is one "better" than the other?

I would use a timer, rather than sleeping. To end it, you could then just stop the timer. — Servy, Aug 14 '12 at 13:29
I've added some observations to may answer, basically I don't think these snippets do what you want. — Jodrell, Aug 14 '12 at 14:20

score 13 · Accepted Answer · answered Aug 14 '12 at 13:45

13

C# volatile does not provide all the guaranties. It may still read stale data. Better to use underlying OS synchronisation mechanism as it provides much stronger guaranties.

All this in great depth discussed by Eric Lippert (really worth reading), here is short quote:

In C#, "volatile" means not only "make sure that the compiler and the jitter do not perform any code reordering or register caching optimizations on this variable". It also means "tell the processors to do whatever it is they need to do to ensure that I am reading the latest value, even if that means halting other processors and making them synchronize main memory with their caches".

Actually, that last bit is a lie. The true semantics of volatile reads and writes are considerably more complex than I've outlined here; in fact they do not actually guarantee that every processor stops what it is doing and updates caches to/from main memory. Rather, they provide weaker guarantees about how memory accesses before and after reads and writes may be observed to be ordered with respect to each other. Certain operations such as creating a new thread, entering a lock, or using one of the Interlocked family of methods introduce stronger guarantees about observation of ordering. If you want more details, read sections 3.10 and 10.5.3 of the C# 4.0 specification.

Frankly, I discourage you from ever making a volatile field. Volatile fields are a sign that you are doing something downright crazy: you're attempting to read and write the same value on two different threads without putting a lock in place. Locks guarantee that memory read or modified inside the lock is observed to be consistent, locks guarantee that only one thread accesses a given hunk of memory at a time, and so on.

answered Aug 14 '12 at 13:45

oleksii

35,458
16
93
163

The volatile works fine here. Any thread writing to one has all its memory updates pushed to main memory. Any thread reading one has its working memory refreshed from main. So a _write_ to a volatile (and the data it references) will be seen by any _read_ from that volatile. That said, the AutoResetEvent looks much better to me in this case. – RalphChapin Aug 14 '12 at 17:14
1

@RalphChapin AFAIK on a multiprocessor systems there are only *weak* guaranties that *all* the processors will see an updated value. – oleksii Aug 14 '12 at 17:24
@oleksii True, but strong enough in this case. Change an object referenced by non-volatile field obj1, then assign it to volatile field obj2. View object on another thread via obj2 and you will see the changes because you "read" obj2, forcing a full memory read. View it via obj1 and you might well see old values in the object, because there was no requirement to read from main memory. (I'm assuming obj1 references the same object in both threads.) There's other weak stuff, too, like the observed sequence of changes with multiple fields. – RalphChapin Aug 14 '12 at 17:53
This all comes from [ECMA-335](http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-335.pdf), section II.12.6. If I'm misinterpreting it, someone let me know! – RalphChapin Aug 14 '12 at 17:58
This is a good answer as I've just tracked down a problem with a thread spinning in a processing loop during a shutdown intermittently back to this exact problem of using a volatile and threads being spread across processors – nrjohnstone Jul 24 '14 at 21:25
Eric Lippert's quote still doesn't quite explain if it is OK to use bool to stop the thread. It only suggests to avoid volatile and use locks instead. If I put a `lock { _keepRunning = false; } ` and `_keepRunning` is just a bool without `volatile` will this force processor to sync `_keepRunning` values for all threads? Or is it still a bad idea and I'd better use Events? – JustAMartin Jan 21 '17 at 17:12
@justamartin If you don't use `volatile bool` then the chances of the value being stale are quite high and your thread may not be stopped ever/in-a-defined-time/soon/immediately. When there are no guarantees, you cannot know the behaviour in advance. In other, words you may use `volatile bool` which will work in nearly all the cases. If you write critical software where you need to be 100% sure the value is updated immediately for all OS and CPU architectures - use events. – oleksii Jan 23 '17 at 10:02
I'm sorry, I did not explain it more accurate. Eric Lippert discourages the use of `volatile` and says: "Locks guarantee that memory read or modified inside the lock is observed to be consistent". But the question is - does this mean that I can totally forget about `volatile` and instead use `lock {}` around value assignments, and I'll be good to go? – JustAMartin Jan 23 '17 at 10:07
1

You probably will be OK. But it's not that what the locks are designed for. They are heavy on performance because they provide some other execution guarantees like ordering, only one thread executes code at a time, the values are refreshed from raw memory and not some sort of cache, etc. In my opinion, using locks for reading immediate values from memory is not efficient, but will do what you are after. A better approach will be to use volatiles (with weak guarantees) or events (strong guarantees) because this is what they have been designed for – oleksii Jan 23 '17 at 10:26

Hans Passant · Answer 2 · 2014-07-29T12:18:11.553

Volatile isn't good enough, but practically it will always work because the operating system scheduler will always take a lock eventually. And will work well on a core with a strong memory model, like x86 which burns a lot of juice to keep caches synchronized between cores.

So what really only matters is how quickly a thread will respond to the stop request. It is easy to measure, just start a Stopwatch in the control thread and record the time after the while loop in the worker thread. The results I measured from repeating taking 1000 samples and taking the average, repeated 10 times:

volatile bool, x86:         550 nanoseconds
volatile bool, x64:         550 nanoseconds
ManualResetEvent, x86:     2270 nanoseconds
ManualResetEvent, x64:     2250 nanoseconds
AutoResetEvent, x86:       2500 nanoseconds
AutoResetEvent, x64:       2100 nanoseconds
ManualResetEventSlim, x86:  650 nanoseconds
ManualResetEventSlim, x64:  630 nanoseconds

Beware that the results for volatile bool are very unlikely to look that well on a processor with a weak memory model, like ARM or Itanium. I don't have one to test.

Clearly it looks like you want to favor ManualResetEventSlim, giving good perf and a guarantee.

One note with these results, they were measured with the worker thread running a hot loop, constantly testing the stop condition and not doing any other work. That's not exactly a good match with real code, a thread won't typically check the stop condition that often. Which makes the differences between these techniques largely inconsequential.

score 3 · Answer 3 · answered Aug 14 '12 at 13:25

3

IMHO the AutoResetEvent is better, because you can't forget the crucial volatile keyword in this case.

answered Aug 14 '12 at 13:25

Daniel Hilgarth

171,043
40
335
443

Jodrell · Answer 4 · 2012-08-14T14:40:49.623

1

Before using the volatile keyword, you should read this and, I guess, when researching multi-threading you could read the whole http://www.albahari.com/threading/ article.

It explains the subtleties of the volatile keyword and why its behaviour can be unexpected.

You'll note, that when using volatile, reads and writes can get reordered which could result in an extra iteration in closely concurrent situations. In this case you may have to wait for around one extra second.

After looking, I don't think your code works for several reasons,

The "boolean:" snippet always sleeps for approximately a second, probably not what you want.

The "AutoResetEvent:" snippet doesen't instantiate _stop and, will always run doWork() at least once.

edited Aug 14 '12 at 14:40

answered Aug 14 '12 at 13:36

Jodrell

34,946
5
87
124

I forgot a `!` on _stop.WaitOne(). These examples are a bit simplified, but basically I want to run `doWork()` periodically. `DoWork()` would run until it has run out of work, after which it has to wait a while for new work to accumulate. – Sjoerd Aug 14 '12 at 14:33
@Sjoerd, I edited my last part. The caution around `volatile` is still pertinent. – Jodrell Aug 14 '12 at 14:42

score 0 · Answer 5 · answered Aug 14 '12 at 13:29

It depends if the above snippet is all you are doing or not. The AutoReset event, as its name suggests, gets reset after the WaitOne is passed. This means that you could then use it again straightaway, rather than with the bool, having to set it back to true.

AutoResetEvent vs. boolean to stop a thread

5 Answers5

Linked