Are primitive types like bool threadsafe ?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Ramesh - 18 Apr 2008 21:20 GMT

Are primitive types like bool threadsafe ? Or do we need to use
synchronization when multiple threads concurrently access a value type ?

Thanks,
Ramesh

Reply to this Message

Peter Duniho - 18 Apr 2008 21:30 GMT

> Are primitive types like bool threadsafe ? Or do we need to use
> synchronization when multiple threads concurrently access a value type ?

32-bit primitives are _sort of_, provided you qualify them with
"volatile". By "sort of" I mean that you can reliably read the value
atomically and write the value atomically. Provided only one writer at
most, you can safely assume that reads will get the entire value, rather
than a partially updated value.

Other than that, no...they are not thread-safe. For example, incrementing
an integer or toggling a boolean requires that you read the value first,
calculate the new value, and then write the new value. Those three
operations together aren't automatically done atomically, and so you need
to synchronize access when doing something like that.

Pete

Reply to this Message

Ramesh - 22 Apr 2008 17:39 GMT

Thanks alot for your responses guys. Out of using volatile, Interlocked and
lock, which option has a better performance, if the shared resource is a
primitive type ?

Thanks,
Ramesh

> > Are primitive types like bool threadsafe ? Or do we need to use
> > synchronization when multiple threads concurrently access a value type ?
[quoted text clipped - 12 lines]
>
> Pete

Reply to this Message

Peter Duniho - 22 Apr 2008 18:33 GMT

> Thanks alot for your responses guys. Out of using volatile, Interlocked
> and
> lock, which option has a better performance, if the shared resource is a
> primitive type ?

"One of those things is not like the others". :)

The "volatile" keyword is not a synchronization construct. It simply
ensures that there's a "memory barrier" to ensure that if one thread has
executed code to write to the variable, that another thread executing code
to read from the variable will see what's written.

If you want synchronization, you need a synchronization object. For
access to simple primitives, the Interlocked class is your best bet
there. Note, however, that the Interlocked class doesn't support the bool
type. Typically this is addressed by using an integer type as a boolean.

Pete

Reply to this Message

Jon Skeet [C# MVP] - 22 Apr 2008 19:17 GMT

> Thanks alot for your responses guys. Out of using volatile, Interlocked and
> lock, which option has a better performance, if the shared resource is a
> primitive type ?

Peter's answer is entirely correct, but doesn't cover one aspect: are
you really sure you need the most performant result? When it comes to
threading, I value correctness *much* higher than performance for
almost all cases. I find it much easier to reason about a lock than
about a volatile variable.

How many times are you expecting to access this variable every second?

Signature

Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

Reply to this Message

Holger Kreissl - 18 Apr 2008 21:30 GMT

> Are primitive types like bool threadsafe ? Or do we need to use
> synchronization when multiple threads concurrently access a value type ?
>
> Thanks,
> Ramesh

Yes they are handled atomically. But use volatile defining it. It says the
compiler not to do any optimizations for the state of the variable.

private volatile bool _atom;

Signature

Holger Kreissl
.NET Software Developer
http://kreissl.blogspot.com/

Reply to this Message

Are primitive types like bool threadsafe ?

Free Magazines