Take the 2-minute tour ×

In c#, is there a way of updating a variable (without using lock) where multiple threads can read the value, but the thread that updates the variable is not considered important.

What I mean is, if a thread updates that value but the other threads don't get that updated value a few minutes later then that is OK.

Is there such a way?

Many thanks

share|improve this question
How is this different than just updating the variable from one thread, and reading from other threads, without adding any thread syncing code? –  mbeckish Aug 30 '09 at 5:20
I don't want to encounter a situation where one thread writes and another reads causing a 'crash' thats all. –  Vince Panuccio Aug 31 '09 at 1:21
add comment

9 Answers

up vote 4 down vote accepted

The best option is to use a ReaderWriterLockSlim (or a ReaderWriterLock if you're not using .net 3.5). Tip: This tutorial should get you started.

share|improve this answer
That is awesome, I was looking for something just like that! –  Brandon Aug 30 '09 at 18:14
add comment

If the updated value is not important to other threads, why the variable is shared between the threads at all? Every thread can use its own copy.

It isn't clear to me. Do you want to intentionally make the delay for reading values or you mean it doesn't matter if other threads can't immediately see the updated value?

In any case, if you want to atomically update a variable without a lock, you should consider using Interlocked methods but I'm not really sure if this is what you need.

share|improve this answer
I'm almost certain he just wants a variable to share between instances of classes (i.e.a static variable). But the general idea is certainly quite questionable. –  Noon Silk Aug 30 '09 at 5:13
add comment

It depends on what you're trying to do. You could mark the field volatile but that may not do you any good. I'm not sure if volatile will insure that incrementing is an atomic operation, for instance. In other words, one of your increments (or other updates) might be "lost" (overwritten by another thread). For that you could use Interlocked.Increment.

Again, it really depends on what you're trying to do. Much of the time it's easiest just to use a lock.

share|improve this answer
add comment

This sounds like it might be a roundabout way to re-invent a caching mechanism. Have you looked into any of the many caching systems available for .NET?

share|improve this answer
add comment

You can atomically update the variable without locking by using Interlocked.CompareExchange until you're successful. This avoids the overhead of locking while ensuring consistency, the following pseudo code should do it, sorry I'm not too familiar with C#.

static void atomic_add(ref int ptr, int addend){
  int previous = *ptr;
    int observed = Interlocked.CompareExchange(ptr, previous+addend, previous);
    if(observed == previous){
      previous = observed;

CompareExchange will replace the value at the first argument with the second argument if the value pointed to by the first argument is equal to the third argument, and returns the value in memory at ptr when CompareExchange was called. If the value returned by compare exchange is the same as the previous value observed at ptr then the value was successfully updated and the loop breaks, otherwise, the value in the pointer changed since its last read and previous is updated and we try again.

From what I've read Interlocked.CompareExchange exists for only int32, floats, and objects (though not sure if that one would be completely lockless?). I imagine it would work for wider values on 64 bit platforms, but I have nothing to back that up.

share|improve this answer
there is an interlocked.add as well. the technique you've described seems to be the best, coupled with thread.volatileread() locks would be overkill for a single variable. –  obelix Aug 30 '09 at 6:11
add comment

Assuming some thread updates your shared variable, if you don't use any synchronization, then your other threads:

  • May or may not read the updated value immediately. If not, they will read it later
  • Will have an inconsistent value (some will get the new value, others will have the updated value) for a short period of time

If these issues are not significant, and if your logic doesn't depend on the value of the shared variable then no synchronization is necessary. Just allow all threads access to the shared variable.

What are you trying to achieve? It will be helpful to get a better answer.


As ShuggyCoUk points out, use this approach with care. It relies on atomic read and writes, which depends on the type of your shared variable. Excerpt from here:


share|improve this answer
if the value is >32bits on some platforms he could get a torn read... –  ShuggyCoUk Aug 30 '09 at 6:51
@shuggy: thanks for the reminder. Is the updated answer more accurate, or is it better to just avoid this in general? –  Nader Shirazie Aug 30 '09 at 7:24
it's a valid answer, and fine so long as the variable is atomic. the problem is people not being aware of the subtlety of it. I have trouble thinking of a useful real world example that could make use of it except with a single writing thread and multiple reading threads. asignment to a reference type to switch in a new object on the fly is about the only one I can think of otherwise. –  ShuggyCoUk Sep 2 '09 at 0:28
add comment

I would put the data into an immutable 'class' (so it is a reference type).

If you want to update the value you first build a new instance and then update the reference to it (which is an atomic operation).

Each reader thread will get the consistent old or the consistent new value (depending of the point in time it reads from the reference). It is not possible to get intermediate results because the data class is immutable!

share|improve this answer
add comment

You might want to take a look into System.Threading.AutoResetEvent or System.Threading.ManualResetEvent.

It allows you to trigger events across threads (value changed). ManualResetEvent might be more appropriate if you want to be lazy on updates...

I'm not sure if you're looking into controlling access to a said variable... In that case, a synchornized method could do the trick:

public void Foo()
    // Do foo

You can also acquire a lock for the said object when modifying its value:

    myObject = new value;
share|improve this answer
Depending on the type of the object, you may need to create a separate synchronization object. See albahari.com/threading/part2.aspx - you can't lock a value type. –  TrueWill Aug 30 '09 at 16:32
add comment

Use .Net types that are natively atomic
It depends what type of variable you're using. Some variables act atomically. Atomic writes means the cpu writes the entire variable in one go, or you can at least consider it as doing so. This means no other thread sees a partially updated variable - which would clearly be bad! Variables that behave atomically would behave as you ask with no locking required.

Assignments to reference types, bool, char, byte, sbyte, short, ushort, uint, int and float are atomic.

I got the list of atomic types here: http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/a5a3c1b4-9f76-43d7-90a6-6572c59491fe

See section 5.5 of the C# specification here: http://download.microsoft.com/download/3/8/8/388e7205-bc10-4226-b2a8-75351c669b09/CSharp%20Language%20Specification.doc

share|improve this answer
add comment

Your Answer


