I learnt the hard way when my multi-threaded app was modifying the same object and the List object couldn’t handle the two thread adding a object to the list at the exact same time.
I did some research and found i can use a lock to avoid this from happening, after a month of the application running smoothly it happend again even with the lock object in place. I don’t understand how this still cab be happening.
the error messages are the same as before:
1- Source array was not long enough. Check srcIndex and length, and the array’s lower bounds.
2- Index was outside the bounds of the array.
in the class private members I have this member variable
private static readonly object _syncLock = new object();
in the public function
public Dictionary<int, QueuedLetter> GetXMLFragment(Dictionary<int, QueuedLetter> queuedLetters, GroupNode GroupNode, GroupNode ParentGroupNode, StoredProcedure storedProcedure)
This is where I use the _synclock object the lines of code are as followed
XmlFragment xf = new XmlFragment();
xf.Fragment = xe;
xf.LetterQueueOID = lq.LetterQueueOID;
xf.ParentGroupNodeName = ParentGroupNodeName;
xf.LinkingField = GroupNode.LinkingField;
xf.GroupNodeName = GroupNode.GroupNodeName;
lock (_syncLock)
{
if (lq.Fragments == null)
lq.Fragments = new List<XmlFragment>();
lq.Fragments.Add(xf);
}
I use a thread pool to create the multi-Threading functionality in another class it calls a starting function in the same class as where the lock happens above
events[i] = new AutoResetEvent(false);
AttachFragments f = new AttachFragments(events[i], groupNodeOID, QueuedLetters, string.Format("Failed while fragment Data : {0}, was executing ", groupNodeName));
f.OnException += ThreadErroredOut;
ThreadPool.QueueUserWorkItem(new WaitCallback(f.UpdateFragments));
If you can give me some advise on what I am doing wrong, that would be greatly appreciated.
I have thought about using
the Thread-Safe Collections in .NET 4.0 http://msdn.microsoft.com/en-us/library/dd997305.aspx
but I haven’t used it and if i change it to this, this would cause big changes in the code which would require a more in depth testing by are Q.A. team.
The stack traces of the two exceptions:
1- Source array was not long enough. Check srcIndex and length, and the array’s lower bounds.:
at System.Array.Copy(Array sourceArray, Int32 sourceIndex, Array destinationArray, Int32 destinationIndex, Int32 length, Boolean reliable) at System.Collections.Generic.List1.Insert(Int32 index, T item) at JE.ThunderHead.Business.AttachFragments.GetXMLFragment(Dictionary2 queuedLetters, GroupNode GroupNode, GroupNode ParentGroupNode, StoredProcedure storedProcedure) in C:\TFS\LMS\Release\LM_05\LM_05.01\Solutions\ThunderHead\JE.Thunderhead.Business\AttachFragments.cs:line 135 at JE.ThunderHead.Business.AttachFragments.UpdateFragments(Object stateinfo) in C:\TFS\LMS\Release\LM_05\LM_05.01\Solutions\ThunderHead\JE.Thunderhead.Business\AttachFragments.cs:line 99
2- Index was outside the bounds of the array:
at System.Collections.Generic.List1.Add(T item) at JE.ThunderHead.Business.AttachFragments.GetXMLFragment(Dictionary2 queuedLetters, GroupNode GroupNode, GroupNode ParentGroupNode, StoredProcedure storedProcedure) in C:\TFS\LMS\Release\LM_05\LM_05.01\Solutions\ThunderHead\JE.Thunderhead.Business\AttachFragments.cs:line 231
From the stack trace you posted, it looks like there’s an
Inserton that list that you’re not showing here. If that’s the case, you’ll need to lock around thatInsertas well using the same lock object.