Circular list as vector, lock needed?
-
Hi I use System.Io.Ports and the serial interface to receive data in a Terminal like application. From the .Net driver I have a DataReceivedHandler where I receive call with each small part of information sent on the serial. the problem: I have seen sometime some "garbage info", data from previous read. I suspect the call come realy fast and it happens sometime to get old data. intention: I want to change my current implementation in this DataReceivedHandler to write in a circular list. This list I intend to be a vector where I put struct having 2 fiels: - a State bit or boolean flag - and the information When I write I just check the state bit (which is similar to a lock), and if it is still false I write the info and increase the indexWrite. and now the question: Whould be safe this implementation without using lock{ circularList } when I receive very fast calls to the DataReceivedHandler? george
-
Hi I use System.Io.Ports and the serial interface to receive data in a Terminal like application. From the .Net driver I have a DataReceivedHandler where I receive call with each small part of information sent on the serial. the problem: I have seen sometime some "garbage info", data from previous read. I suspect the call come realy fast and it happens sometime to get old data. intention: I want to change my current implementation in this DataReceivedHandler to write in a circular list. This list I intend to be a vector where I put struct having 2 fiels: - a State bit or boolean flag - and the information When I write I just check the state bit (which is similar to a lock), and if it is still false I write the info and increase the indexWrite. and now the question: Whould be safe this implementation without using lock{ circularList } when I receive very fast calls to the DataReceivedHandler? george
Probably not - IIRC none of the .NET Collections are intrinsically thread safe, and they should all be locked. Either use the .NET Queue[^] with a lock or homebrew a safe version. If you are just using a single in-feed and a single out-feed, you don't need to use locking if you write it correctly. One way is to use an array, with two indexes - input and output. If insert only affects the input, and remove only affects the output, the only time they need to both be checked is for a full/empty test, which shouldn't need a lock - it would if you used more than one input source, or more than one remover.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
Probably not - IIRC none of the .NET Collections are intrinsically thread safe, and they should all be locked. Either use the .NET Queue[^] with a lock or homebrew a safe version. If you are just using a single in-feed and a single out-feed, you don't need to use locking if you write it correctly. One way is to use an array, with two indexes - input and output. If insert only affects the input, and remove only affects the output, the only time they need to both be checked is for a full/empty test, which shouldn't need a lock - it would if you used more than one input source, or more than one remover.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
OriginalGriff wrote:
IIRC none of the .NET Collections are intrinsically thread safe
Actually, .NET 4 introduced the System.Collections.Concurrent namespace[^], which includes a
ConcurrentQueue. However, IIRC there's the potential for a delayed garbage collection - the queue keeps a reference to the object even after it's dequeued until it's been overwritten in the queue's buffer. This becomes more of an issue with a large-capacity queue. Our workaround was to use the Mono implementation of the ConcurrentQueue instead (it doesn't have this problem).The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen
-
OriginalGriff wrote:
IIRC none of the .NET Collections are intrinsically thread safe
Actually, .NET 4 introduced the System.Collections.Concurrent namespace[^], which includes a
ConcurrentQueue. However, IIRC there's the potential for a delayed garbage collection - the queue keeps a reference to the object even after it's dequeued until it's been overwritten in the queue's buffer. This becomes more of an issue with a large-capacity queue. Our workaround was to use the Mono implementation of the ConcurrentQueue instead (it doesn't have this problem).The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen
Didn't know that - have a five!
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
Probably not - IIRC none of the .NET Collections are intrinsically thread safe, and they should all be locked. Either use the .NET Queue[^] with a lock or homebrew a safe version. If you are just using a single in-feed and a single out-feed, you don't need to use locking if you write it correctly. One way is to use an array, with two indexes - input and output. If insert only affects the input, and remove only affects the output, the only time they need to both be checked is for a full/empty test, which shouldn't need a lock - it would if you used more than one input source, or more than one remover.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
OriginalGriff wrote:
thread safe
New in .NET 4, http://msdn.microsoft.com/en-us/library/dd997305.aspx[^] [Edit] Never mind. OP already posted that.
Why is common sense not common? Never argue with an idiot. They will drag you down to their level where they are an expert. Sometimes it takes a lot of work to be lazy Please stand in front of my pistol, smile and wait for the flash - JSOP 2012
-
Probably not - IIRC none of the .NET Collections are intrinsically thread safe, and they should all be locked. Either use the .NET Queue[^] with a lock or homebrew a safe version. If you are just using a single in-feed and a single out-feed, you don't need to use locking if you write it correctly. One way is to use an array, with two indexes - input and output. If insert only affects the input, and remove only affects the output, the only time they need to both be checked is for a full/empty test, which shouldn't need a lock - it would if you used more than one input source, or more than one remover.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
yes this was my intention to have to indexes one for read, one for write, and because it is in a Handlerfunction it should be executed very fast so I will use a vector - as the circular list (or Buffer). I will try this solution first, after the other with the Thread safe collections. thx
-
yes this was my intention to have to indexes one for read, one for write, and because it is in a Handlerfunction it should be executed very fast so I will use a vector - as the circular list (or Buffer). I will try this solution first, after the other with the Thread safe collections. thx
probably I need some kind of lightweight lock, bacause the call to the Handler can come realy fast and mess up with my array index, which is already done in ConcurrentQueue Class. Even if I use a state bit on every element the index could be messed up by another call just before it is used. I have been wondering how it is implemented. Would be possible this class: ConcurrentQueue Class to e implemented using just Interlock class witout any SpinWait or while loops?
