I have this method:
public bool Remove(EntityKeyType key)
{
lock (syncroot)
{
//wait if we need to
waitForContextMRE.Wait();
//if the item is not local, assume it is not remote.
if (!localCache.ContainsKey(key)) return false;
//build an expression tree
Expression<Func<EntityType, bool>> keyComparitorExpression = GenerateKeyComparitorExpression(key);
var itemToDelete = TableProperty.Single(keyComparitorExpression);
//delete from db
TableProperty.DeleteOnSubmit(itemToDelete);
DataContext.SubmitChanges();
//get the removed item for OnCollectionChanged
EntityType itemToRemove = localCache[key];
itemToRemove.PropertyChanged -= item_PropertyChanged;
//remove from the list
Debug.Assert(localCache.Remove(key));
//call the notification
OnCollectionChanged(new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Remove, itemToRemove));
return true;
}
}
I am calling it from multiple threads (calling the same instance), but an exception keeps being thrown on TableProperty.Single (Sequence contains no elements). Upon debugging the code I saw that a situation is being created where the item is being deleted from the database after a different thread has checked the cache for its existence. This should not be possible unless there are multiple threads inside the lock statement (The syncroot object is definitely the same instance across threads).
Impossible? I have proof:
There are three threads inside the lock statement! What gives?
notes:
Update
This is the declaration of the syncroot object:
private object syncroot = new object();
And some other declarations:
private ManualResetEventSlim waitForContextMRE = new ManualResetEventSlim(true);
private DataContextType _dataContext;
private System.Data.Linq.Table<EntityType> _tableProperty;
//DataContextType and EntityType are generic type parameters
I cannot make the syncroot static because I have several instances of the class running and it is important that they don't block each other. But that doesn't really matter - making it static does not fix the problem.
The ManualResetEvent (waitForContextMRE) is not there for synchronization - it's there to block database operations for a certain time after certain operations are performed (ie on startup). It is set most of the time. Taking it out of the lock block also does not fix the problem.
The only explanation I have is that waitForContextMRE.Wait(); calling this makes the thread do unblock syncroot! And so other thread can enter lock section. Try to move waitForContextMRE.Wait(); before lock(...).
I think that you are calling different objects. There is no indication on your screenshot that you are taking values from different threads. Also using non static syncroot is not a good idea because may result in cases like yours. Do you have really strong reason not to have it static?
我建议锁定TableProperty或DataContext
I have been debugging this problem for a while now and, although I have not resolved it, it is clear to me that the locks are working . I am guessing the problem is with the DataContext (which are known for being tricky in multithreaded situations).
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.