   Concurrency and locking, is this right or reasonable?
  Suppose this scenario (C#.NET 2 if it's relevant):I have an array of objects.  Every time I get an event or do something in a thread, I lock an object to do something on it and then release it.  I also have a timer set to do something to the whole array every 10 minutes, which involves another lock/release.  Sounds fairly safe, as far as I can tell.Having removed the question about order of response (I saw the word queue, implying sequential given all requests block until the current ends, somewhere right after posting), is the idea itself overkill?  I find I have a tendency to overdesign parts of software that would probably be "good enough."   
  No it's not overkill if you simply want to prevent reading a partially updated array etc.There are times when you can avoid needing to lock though:If you only have one thread that is ever allowed to modify the array, then although that thread must lock it when writing to it and all other threads must lock it when reading from it, the writing thread doesn't have to lock it when only reading from it. This is because nothing else can modify it.   ;  It's kinda hard to say, if it's gonna be an overkill since it depends on the event frequency, thread count, etc. The problem is that you have no other choice - you have to lock shared objects or you are asking for trouble.The only thing I can recommend is to keep your lock sections as small as possible. Also, if possible, try to lock only the members you are going to modify (or read) and not the whole object. And you know you can't lock value types, right?;) (geez, I hate threading)   ;  Digibo: have a look at lock-free synchronization (introduction). An alternative in this case would be to store pointers to data in the array; when processing items, do work on a separate copy and atomically update (called "swing in", via CAS) the pointer afterwards.   ;  I wouldn't worry too much about overkill when it comes to multithreading. Overkill is by far a better solution than just missing one possible deadlock/race condition/anything else.If there's the slightest chance of a thread accessing an object while another is updating it, it's going to happen, and crash your program. So it's only overkill if you can guarantee with 100% certainty that it would *never* be a problem even without whatever synchronization mechanism you're using.If you have the slightest doubt about whether you can do without it, keep it. Overkill or not.   ;  I wouldn't be quite so agressive as SpoonBender about dismissing overkill, imho you definitely need to keep it in mind.  It's pretty easy to write a multithreaded app that performs worse than a single threaded app because of excessive locking and serialization.  You also run greater risks of deadlocks.Unfortunately there's no easy answer to your question.  I do agree that it's better err on the side of to much locking, especially for the beginner.   ;Quote:Original post by Anon Mike[...]It's pretty easy to write a multithreaded app that performs worse than a single threaded app because of excessive locking and serialization.[...]In general, multithreaded apps will run slower anyways since multicore and/or multiprocessor machines aren't standard yet. Of course, if you have an x2 or equiv and the program is only for your own use, you can can considerable performance but it takes work the same way single-threaded optimization does.The only reason multithreaded apps are harder to make for most people is that few have experience with it on multiprocessor systems where the problems are greatly amplified.;  AFAIK, synchronization hurts you when two threads actually collide, because one must stall on the data. So if you don't expect concurrent access very much (one every 10 minutes is certainly not very frequent) then this is fine. Now an alternative you might want to consider is using a single lock to lock the ENTIRE list. Since you only have two clients accessing the data, and one client only accesses the data every 10 minutes, the list's lock will almost never stall.   ;Quote:Original post by ExtrariusIn general, multithreaded apps will run slower anyways since multicore and/or multiprocessor machines aren't standard yet.Nah, most normal apps are I/O bound (at least in my experience).  You can use worker threads to do background stuff and get a big win in perceived performance even on an ordinary single-proc, single-core, non-hyper-threaded system.   ;Quote:Original post by Anon Mike[...]Nah, most normal apps are I/O bound (at least in my experience).  You can use worker threads to do background stuff and get a big win in perceived performance even on an ordinary single-proc, single-core, non-hyper-threaded system.From what I've read, it sounds like overlapped I/O is faster than multithreaded blocking I/O, and if you have something to do while waiting for I/O besides wait, it seems that would be a much simpler way to do it.Also, IME when a program waits for something (in the sense of I/O, synchronization, etc) do so because they need whatever they're waiting on before they can continue. The only common exception I can think of is having an extra thread for the GUI so that it properly updates etc reguardless of what is going on in the worker thread.Further links on the lock-free synchronization would be apprciated. The powerpoint is nice, but it pretty much avoids explaining anything at all. All the papers it references seem to be at not-$0 places.   