I have class Lazy which lazily evaluates an expression:
public sealed class Lazy<T>
{
Func<T> getValue;
T value;
public Lazy(Func<T> f)
{
getValue = () =>
{
lock (getValue)
{
value = f();
getValue = () => value;
}
return value;
};
}
public T Force()
{
return getValue();
}
}
Basically, I'm trying to avoid the overhead of locking objects after they've been evaluated, so I replace getValue with another function on invocation.
It apparently works in my testing, but I have no way of knowing if it'll blow up in production.
Is my class threadsafe? If not, what can be done to guarantee thread safety?
Can’t you just omit re-evaluating the function completely by either using a flag or a guard value for the real value? I.e.:
public sealed class Lazy<T>
{
Func<T> f;
T value;
volatile bool computed = false;
void GetValue() { lock(LockObject) { value = f(); computed = true; } }
public Lazy(Func<T> f)
{
this.f = f;
}
public T Force()
{
if (!computed) GetValue();
return value;
}
}
Your code has a few issues:
You need one object to do the locking on. Don't lock on a variable that gets changed - locks always deal with objects, so if getValue is changed, multiple threads might enter the locked section at once.
If multiple threads are waiting for the lock, all of them will evaluate the function f() after each other. You'd have to check inside the lock that the function wasn't evaluated already.
You might need a memory barrier even after fixing the above issues to ensure that the delegate gets replaced only after the new value was stored to memory.
However, I'd use the flag approach from Konrad Rudolph instead (just ensure you don't forget the "volatile" required for that). That way you don't need to invoke a delegate whenever the value is retrieved (delegate calls are quite fast; but not they're not as fast as simply checking a bool).
I'm not entirely sure what you're trying to do with this code, but I just published an article on The Code Project on building a sort of "lazy" class that automatically, asynchronously calls a worker function and stores its value.
This looks more like a caching mechanism than a "lazy evaluation". In addition, do not change the value of a locking reference within the lock block. Use a temporary variable to lock on.
The wait you have it right now would work in a large number of cases, but if you were to have two different threads try to evaluate the expression in this order:
Thread 1
Thread 2
Thread 1 completes
Thread 2 would never complete, because Thread 1 would be releasing a lock on a different reference than was used to acquire the lock (more precisely, he'd be releasing a nonexistent lock, since the newly-created reference was never locked to begin with), and not releasing the original lock, which is blocking Thread 2.
While I'm not entirely certain what this would do (aside from perform a synchronized evaluation of the expression and caching of the result), this should make it safer:
public sealed class Lazy<T>
{
Func<T> getValue;
T value;
object lockValue = new object();
public Lazy(Func<T> f)
{
getValue = () =>
{
lock (lockValue)
{
value = f();
getValue = () => value;
}
return value;
};
}
public T Force()
{
return getValue();
}
}
Related
Let's say I have a method that gets called by multiple threads
public class MultiThreadClass
{
public void Gogogo()
{
// method implementation
}
private volatile bool running;
}
in Gogogo(), I want to check if running is true, and if so, return from the method. However, if it is false, I want to set it to true and continue the method. The solution I see is to do the following:
public class MultiThreadClass
{
public void Gogogo()
{
lock (this.locker)
{
if (this.running)
{
return;
}
this.running = true;
}
// rest of method
this.running = false;
}
private volatile bool running;
private readonly object locker = new object();
}
Is there another way to do this? I've found out that if I leave out the lock, running could be false for 2 different threads, set to true, and the rest of the method would execute on both threads simultaneously.
I guess my goal is to have the rest of my method execute on a single thread (I don't care which one) and not get executed by the other threads, even if all of them (2-4 in this case) call Gogogo() simultaneously.
I could also lock on the entire method, but would the method run slower then? It needs to run as fast as possible, but part of it on only one thread at a time.
(Details: I have a dicionary of ConcurrentQueue's which contain "results" which have "job names". I am trying to dequeue one result per key in the dictionary (one result per job name) and call this a "complete result" which is sent by an event to subscribers. The results are sent via an event to the class, and that event is raised from multiple threads (one per job name; each job raises a "result ready" event on it's own thread)
You can use Interlocked.CompareExchange if you change your bool to an int:
private volatile int running = 0;
if(Interlocked.CompareExchange(ref running, 1, 0) == 0)
{
//running changed from false to true
}
I think Interlocked.Exchange should do the trick.
You can use Interlocked to handle this case without a lock, if you really want to:
public class MultiThreadClass
{
public void Gogogo()
{
if (Interlocked.Exchange(ref running, 1) == 0)
{
//Do stuff
running = 0;
}
}
private volatile int running = 0;
}
That said, unless there is a really high contention rate (which I would not expect) then your code should be entirely adequate. Using Interlocked also suffers a bit in the readability department due to not having bool overloads for their methods.
You need to use Monitor class instead of boolean flag. Use Monitor.TryEnter:
public void Gogogo()
{
if Monitor.TryEnter(this.locker)
{
try
{
// Do stuff
}
finally
{
Monitor.Exit(this.locker);
}
}
}
Is it correct to use double check locking with not static fields?
class Foo
{
private SomeType member;
private readonly object memeberSync = new object();
public SomeType Memeber
{
get
{
if(member == null)
{
lock(memeberSync)
{
if(member == null)
{
member = new SomeType();
}
}
}
return object;
}
}
}
Is it correct to use double check locking with not static fields?
Yes, nothing wrong with your code to use double checking with lock to get thread-safe and lazy loading. If you are using from .NET 4, it would be suggested using Lazy class, this approach get the same result with thread-safe and lazy loading but it also makes your code simpler, more readable.
class Foo
{
private readonly Lazy<SomeType> _member =
new Lazy<SomeType>(() => new SomeType());
public SomeType Member
{
get { return _member.Value; }
}
}
The outer check gives a performance boost in that, once member is initialised, you don't have to obtain the lock every time you access the property. If you're accessing the property frequently from multiple threads, the performance hit of the lock could be quite noticeable.
The inner check is necessary to prevent race conditions: without that, it would be possible for two threads to process the outer if statement, and then both would initialise member.
Strictly speaking, the outer if isn't necessary, but it's considered good practise and (in a heavily-threaded application) the performance benefit would be noticeable.
It is a practice recommended by some because your lock may not apply until another lock is released.
In this case two threads access the getter at the same time, the first one gets the lock and the second waits.
Once the first is finished, the second thread now has the lock.
In cases where this is possible, you should check to see if the variable has already been created by another thread before the current thread acquired lock.
Is the following object thread safe?
I'll make one instance and use it using two or more threads, is this a good way to approach this?
public class ASyncBuffer<T>
{
readonly object _locker = new object();
private T _value;
private bool _dirty;
public T GetValue()
{
lock (_locker)
{
_dirty = false;
return _value;
}
}
public void SetValue(T value)
{
lock (_locker)
{
_dirty = true;
_value = value;
}
}
public bool Dirty
{
get
{
lock (_locker)
{
return _dirty;
}
}
}
}
The object itself is thread safe, but make sure you consider your usage of it as well. For example, if your usage looks like this:
if ( buffer.Dirty ) {
var obj = buffer.GetValue();
}
That usage is NOT thread safe since the value of Dirty could change between when you check it and when you actually get the value.
To avoid that issue (and make minimal use of locking), you would want to use it like so:
if ( buffer.Dirty ) {
lock(buffer) {
if ( buffer.Dirty ) {
var obj = buffer.GetValue();
}
}
}
In short: no really.
Once you relinquish ownership of the value, then you can make absolutely no guarantees as to what's going to happen. This becomes particularly more pronounced when you rely on _value to have a certain value (no pun intended) in something like an if-statement. When that happens, all you've guaranteed is that the _value will not be in some partial writing state when its read.
The same is true for the dirty flag... frankly it's even more pronounced with the dirty flag.
Consider this case:
Thread 1 calls ASyncBuffer.SetValue(someValue) // sets the dirty flag to true
Thread 1 checks ASyncBuffer.Dirty // should be true
Thread 2 calls ASyncBuffer.GetValue() // sets the flag to false
Thread 1 calls ASyncBuffer.GetValue() // you expect the dirty flag to be true, but it's not
In that sense, it's not thread safe.
YES but only when accessing the property itself, as soon as the property is being used/assigned then it is up to the object being manipulated to handle its internal state being manipulated in a thread-safe manner.
Yes, but it's use might not be.
I'm assuming that you want to retrieve the value if and only if it's "dirty" (since that gets cleared on each retrieval, so I can't see the value in the opposite). You would therefore do:
if(buff.Dirty)
{
T val = buff.GetValue();
//operations on val.
}
However, if another thread calls GetValue() at the same time, then Dirty is now false.
Hence, its use is only safe for one reader thread (multiple writer threads is fine in this case, as they only ever change Dirty in the opposite direction).
If you could have multiple readers, then consider adding something like:
public bool GetIfDirty(out T value)
{
lock (_locker)
{
if(!_dirty)
{
value = default(T);
return false;
}
_dirty = false;
value = _value;
return true;
}
}
Then you can both test Dirty and obtain the value if wanted, in the same threadsafe operation.
AFAIK, this is not a thread safe program. Your getter and setter will have different locks. Refer thread for more information
I know that is wrong to use lock(this) or any shared object.
I wonder if this usage is OK?
public class A
{
private readonly object locker = new object();
private List<int> myList;
public A()
{
myList = new List<int>()
}
private void MethodeA()
{
lock(locker)
{
myList.Add(10);
}
}
public void MethodeB()
{
CallToMethodInOtherClass(myList);
}
}
public class OtherClass
{
private readonly object locker = new object();
public CallToMethodInOtherClass(List<int> list)
{
lock(locker)
{
int i = list.Count;
}
}
}
Is this thread safe? In OtherClass we lock with a private object so if the class A lock with its private lock can the list still change in the the lock block in OtherClass?
No, it's not thread safe. Add and Count may be executed at the "same" time. You have two different lock objects.
Always lock your own lock object when passing the list:
public void MethodeB()
{
lock(locker)
{
CallToMethodInOtherClass(myList);
}
}
No this is not thread safe. To make it thread safe you can use lock on static objects because they are shared between threads, this may cause deadlocks in the code but it can be handle by maintaining proper order for locking. There is a performance cost associated with lock so use it wisely.
Hope this helps
No, this is not thread-safe. A.MethodeA and OtherClass.CallToMethodInOtherClass are locking on different objects, so they're not mutually exclusive. If you need to protect the access to the list, don't pass it to external code, keep it private.
No, that is not thread-safe.
Your 2 methods are locking on 2 different objects, they will not lock out each other.
Because CallToMethodInOtherClass() only retrieves the value of Count nothing will go horribly wrong. But the lock() around it is useless and misleading.
If the method would make changes in the list you would have a nasty problem. To solve it, change MethodeB:
public void MethodeB()
{
lock(locker) // same instance as MethodA is using
{
CallToMethodInOtherClass(myList);
}
}
No, they have to lock the same object. With your code they both lock on a different and each call could be executed simultaneous.
To make the code thread safe place a lock in MethodeB or use the list itself as lock object.
It actually is thread-safe (purely as a matter of an implementation detail on Count), but:
Thread-safe snippets of code do not a thread-safe application make. You can combine different thread-safe operations into non-thread-safe operations. Indeed, much non-thread-safe code can be broken down into smaller pieces all of which are thread-safe on their own.
It's not thread-safe for the reason you were hoping, which means that extending it further would not be thread-safe.
This code would be thread-safe:
public void CallToMethodInOtherClass(List<int> list)
{
//note we've no locks!
int i = list.Count;
//do something with i but don't touch list again.
}
Call it with any list, and it'll give i a value based on the state of that list, regardless of what other threads are up to. It will not corrupt list. It will not give i an invalid value.
So while this code is also thread-safe:
public void CallToMethodInOtherClass(List<int> list)
{
Console.WriteLine(list[93]); // obviously only works if there's at least 94 items
// but that's nothing to do with thread-safety
}
This code would not be thread-safe:
public void CallToMethodInOtherClass(List<int> list)
{
lock(locker)//same as in the question, different locker to that used elsewhere.
{
int i = list.Count;
if(i > 93)
Console.WriteLine(list[93]);
}
}
Before going further, the two bits I described as thread-safe are not promised to be by the spec for List. Conservative coding would assume they are not thread-safe rather than depending upon implementation details, but I'm going to depend on the implementation details because it affects the question of how to use locks in an important way:
Because there is code operating on list that is not acquiring the lock on locker first, that code is not prevented from running concurrently with CallToMethodInOtherClass. Now, while list.Count is thread-safe and list[93] is tread-safe,* the combination of the two where we depend on the first to ensure that the second works is not thread-safe. Because code outside the lock can affect list, it's possible for code to call Remove or Clear in between Count assuring us that list[93] would work, and list[93] being called.
Now, if we know that list is only ever added to, that's fine, even if a resize is happening concurrently we'll end up with the value of list[93] either way. If something is writing to list[93] and it's a type that .NET will write to atomically (and int is one such type), we'll end up with either the old one or the new one, just as if we'd locked correctly we'd get the old or the new depending on which thread go the lock first. Again, this is an implementation detail not a specified promise, I'm stating this just to point out how the thread-safety given still results in non thread-safe code.
Moving this toward real code. We shouldn't assume that list.Count and list[93] is threadsafe because we weren't promised they would be and that could change, but even if we did have that promise, those two promises won't add up to a promise that they'd be thread-safe together.
The important thing is to use the same lock to protect blocks of code that can interfere with each other. Hence, consider the variant below that is guaranteed to be threadsafe:
public class ThreadSafeList
{
private readonly object locker = new object();
private List<int> myList = new List<int>();
public void Add(int item)
{
lock(locker)
myList.Add(item);
}
public void Clear()
{
lock(locker)
myList.Clear();
}
public int Count
{
lock(locker)
return myList.Count;
}
public int Item(int index)
{
lock(locker)
return myList[index];
}
}
This class is guaranteed to be thread-safe in everything it does. Without depending on any implementation details, there is no method here that will corrupt state or give incorrect results because of what another thread is doing with the same instance. The following code still doesn't work though:
// (l is a ThreadSafeList visible to multiple threads.
if(l.Count > 0)
Console.WriteLine(l[0]);
We've guaranteed the thread-safety of each call 100%, but we haven't guaranteed the combination, and we can't guarantee the combination.
There's two things we can do. We can add a method for the combination. Something like the following would be common for many classes specifically designed for multi-threaded use:
public bool TryGetItem(int index, out int value)
{
lock(locker)
{
if(l.Count > index)
{
value = l[index];
return true;
}
value = 0;
return false;
}
}
This makes the count test and the item retrieval part of a single operation which is guaranteed to be thread-safe.
Alternatively, and most often what we need to do, we have the lock happen at the place where the operations are grouped:
lock(lockerOnL)//used by every other piece of code operating on l
if(l.Count > 0)
Console.WriteLine(l[0]);
Of course, this makes the locks within ThreadSafeList redundant and just a waste of effort, space, and time. This is the main reason that most classes don't provide thread-safety on their instance members - since you can't meaningfully protect groups of calls on members from within the class, it's a waste of time trying to unless the thread-safety promises are very well specified and useful on their own.
To come back to the code in your question:
The lock in CallToMethodInOtherClass should be removed unless OtherClass has its own reason for locking internally. It can't make a meaningful promise that it won't be combined in a non-threadsafe way and adding more locks to a program just increases the complexity of analysing it to be sure there are no deadlocks.
The call to CallToMethodInOtherClass should be protected by the same lock as other operations in that class:
public void MethodeB()
{
lock(locker)
CallToMethodInOtherClass(myList);
}
Then as long as CallToMethodInOtherClass doesn't store myList somewhere it can be seen by other threads later on, it doesn't matter that CallToMethodInOtherClass isn't thread-safe because the only code that can access myList brings its own guarantee not to call it concurrently with other operations on myList.
The two important things are:
When something is described as "thread-safe", know just what it's promising by that, as there are different sorts of promise that fall under "thread-safe" and on its own it just means "I won't put this object into a nonsensical state", which while an important building block, is not a lot on its own.
Lock on groups of operations, with the same lock for each group that'll affect the same data, and guard the access to objects so that there can't possibly be another thread not playing ball with this.
*This is a very limited definition of thread-safe. Calling list[93] on a List<T> where T is a type that will be written and read atomically and we don't know whether it actually has at least 94 items is equally safe whether or not there are other threads operating on it. Of course, the fact that it can throw ArgumentOutOfRangeException in either case is not what most people would consider "safe", but the guarantee we have with multiple threads remains the same as with one. It's that we obtain a stronger guarantee by checking Count in a single thread but not in a multi-thread situation that leads me to describe that as not thread-safe; while that combo still won't corrupt state it can lead to an exception we'd assured ourselves couldn't happen.
Probably the easiest way to do the trick
public class A
{
private List<int> myList;
public A()
{
myList = new List<int>()
}
private void MethodeA()
{
lock(myList)
{
myList.Add(10);
}
}
public void MethodeB()
{
CallToMethodInOtherClass(myList);
}
}
public class OtherClass
{
public CallToMethodInOtherClass(List<int> list)
{
lock(list)
{
int i = list.Count;
}
}
}
Many of the answers have mentioned using a static readonly lock.
However, you really should try to avoid this static lock. It would be easy to create a deadlock where multiple threads are using the static lock.
What you could use instead is one of the .net 4 concurrent collections, these do provide some thread synchronisation on your behalf, so that you do not need to use the locking.
Take a look at the System.collections.Concurrent namespace.
For this example, you could use the ConcurrentBag<T> class.
Ass all the answers say these are different lock objects.
a simple way is to have a static lock object f.ex:
publc class A
{
public static readonly object lockObj = new object();
}
and in both classes use lock like:
lock(A.lockObj)
{
}
Okay, I just can't get my head around multi-threading scenarios properly. Sorry for asking a similar question again, I'm just seeing many different "facts" around the internet.
public static class MyClass {
private static List<string> _myList = new List<string>;
private static bool _record;
public static void StartRecording()
{
_myList.Clear();
_record = true;
}
public static IEnumerable<string> StopRecording()
{
_record = false;
// Return a Read-Only copy of the list data
var result = new List<string>(_myList).AsReadOnly();
_myList.Clear();
return result;
}
public static void DoSomething()
{
if(_record) _myList.Add("Test");
// More, but unrelated actions
}
}
The idea is that if Recording is activated, calls to DoSomething() get recorded in an internal List, and returned when StopRecording() is called.
My specification is this:
StartRecording is not considered Thread-Safe. The user should call this while no other Thread is calling DoSomething(). But if it somehow could be, that would be great.
StopRecording is also not officially thread-safe. Again, it would be great if it could be, but that is not a requirement.
DoSomething has to be thread-safe
The usual way seems to be:
public static void DoSomething()
{
object _lock = new object();
lock(_lock){
if(_record) _myList.Add("Test");
}
// More, but unrelated actions
}
Alternatively, declaring a static variable:
private static object _lock;
public static void DoSomething()
{
lock(_lock){
if(_record) _myList.Add("Test");
}
// More, but unrelated actions
}
However, this answer says that this does not prevent other code from accessing it.
So I wonder
How would I properly lock a list?
Should I create the lock object in my function or as a static class variable?
Can I wrap the functionality of Start and StopRecording in a lock-block as well?
StopRecording() does two things: Set a boolean variable to false (to prevent DoSomething() from adding more stuff) and then copying the list to return a copy of the data to the caller). I assume that _record = false; is atomic and will be in effect immediately? So normally I wouldn't have to worry about Multi-Threading here at all, unless some other Thread calls StartRecording() again?
At the end of the day, I am looking for a way to express "Okay, this list is mine now, all other threads have to wait until I am done with it".
I will lock on the _myList itself here since it is private, but using a separate variable is more common. To improve on a few points:
public static class MyClass
{
private static List<string> _myList = new List<string>;
private static bool _record;
public static void StartRecording()
{
lock(_myList) // lock on the list
{
_myList.Clear();
_record = true;
}
}
public static IEnumerable<string> StopRecording()
{
lock(_myList)
{
_record = false;
// Return a Read-Only copy of the list data
var result = new List<string>(_myList).AsReadOnly();
_myList.Clear();
return result;
}
}
public static void DoSomething()
{
lock(_myList)
{
if(_record) _myList.Add("Test");
}
// More, but unrelated actions
}
}
Note that this code uses lock(_myList) to synchronize access to both _myList and _record. And you need to sync all actions on those two.
And to agree with the other answers here, lock(_myList) does nothing to _myList, it just uses _myList as a token (presumably as key in a HashSet). All methods must play fair by asking permission using the same token. A method on another thread can still use _myList without locking first, but with unpredictable results.
We can use any token so we often create one specially:
private static object _listLock = new object();
And then use lock(_listLock) instead of lock(_myList) everywhere.
This technique would have been advisable if myList had been public, and it would have been absolutely necessary if you had re-created myList instead of calling Clear().
Creating a new lock in DoSomething() would certainly be wrong - it would be pointless, as each call to DoSomething() would use a different lock. You should use the second form, but with an initializer:
private static object _lock = new object();
It's true that locking doesn't stop anything else from accessing your list, but unless you're exposing the list directly, that doesn't matter: nothing else will be accessing the list anyway.
Yes, you can wrap Start/StopRecording in locks in the same way.
Yes, setting a Boolean variable is atomic, but that doesn't make it thread-safe. If you only access the variable within the same lock, you're fine in terms of both atomicity and volatility though. Otherwise you might see "stale" values - e.g. you set the value to true in one thread, and another thread could use a cached value when reading it.
There are a few ways to lock the list. You can lock on _myList directly providing _myList is never changed to reference a new list.
lock (_myList)
{
// do something with the list...
}
You can create a locking object specifically for this purpose.
private static object _syncLock = new object();
lock (_syncLock)
{
// do something with the list...
}
If the static collection implements the System.Collections.ICollection interface (List(T) does), you can also synchronize using the SyncRoot property.
lock (((ICollection)_myList).SyncRoot)
{
// do something with the list...
}
The main point to understand is that you want one and only one object to use as your locking sentinal, which is why creating the locking sentinal inside the DoSomething() function won't work. As Jon said, each thread that calls DoSomething() will get its own object, so the lock on that object will succeed every time and grant immediate access to the list. By making the locking object static (via the list itself, a dedicated locking object, or the ICollection.SyncRoot property), it becomes shared across all threads and can effectively serialize access to your list.
The first way is wrong, as each caller will lock on a different object.
You could just lock on the list.
lock(_myList)
{
_myList.Add(...)
}
You may be misinterpreting the this answer, what is actually being stated is that they lock statement is not actually locking the object in question from being modified, rather it is preventing any other code using that object as a locking source from executing.
What this really means is that when you use the same instance as the locking object the code inside the lock block should not get executed.
In essence you are not really attempting to "lock" your list, you are attempting to have a common instance that can be used as a reference point for when you want to modify your list, when this is in use or "locked" you want to prevent other code from executing that would potentially modify the list.