   Locking with threads
  Using threads is still a new thing to me, so I have some questions about accessing data from multiple threads.   First off im using C#.  I have a data structure...  byte <List> dataBuffer; (this holds the incoming network data)Now I am using BeginRead to call a function on a seperate thread every time I recieve packets from the client. So every time i get a new packet from the server I am adding the data to 'dataBuffer' with 'dataBuffer.AddRange(data);'And I also have my game loop (XNA) reading 'dataBuffer' and removing the data from the beginning of the list as I read it.So its a sort of 'first in first out' set upWhat I dont want to happen is for data to be added to the tail of the list, while im reading data from the head of the list.I know locking can prevent this, I just dont understand how to do it.Do I lock in the read data function, or the write data function, or both?What happens if a Lock fails? (trying to lock the dataBuffer when its already locked by another thread?)Any links to, or replies of helpful information is greatly appreciated.  Thanks :)   
  The simplest (but not best) way to make your message queue safe is to lock when someone is reading it or when someone is writing it. If you reader acquires the lock then the writer will, when trying to acquire the lock, either wait (if it's a blocking call) or return some sort of error (if it's a non blocking call.)A better way is to use a Read/Write semaphore (google that!) which allows many reads at the same time but no writes, or one write and no reads.This is a classic problem taught in every computer science course that touches on concurrency--it's called the producer/consumer problem, where there's a producing thread that fills a queue and a consuming thread that empties it. (google that as well!)Hope this helps.   ;  Ok after googling a bit this is what I think...  The semaphore thing seemed a bit over-complicated for me.  As for my setup, I dont think I will ever have more than 1 reader, but if I did, I would still need to keep from having more than 1 reader access the data, since each reader, also removes data.  I looked at the whole locking thing, and from what I can make out...  If I want a blocking call (i need the writers to wait so they can go ahead and read in the data sent from the network)So... in my writers, Im guessing i need to do thislock (dataBuffer){dataBuffer.AddRange(data);}If im understanding correct, thsi should block the thread until any lock call is finished on dataBuffer, right?for my reader, i guess it would be impractical to block since the reader tied into the main game loop, so i should use non blocking... guessing like this...try{lock (dataBuffer){do read}}catch {}so if im understanding this, will it go to the catch if the dataBuffer is locked by another process?Thanks for the help;  Both of those methods will block.  Calling lock inside a try-block doesn't make it non-blocking.What you're looking for is TryEnter.The 'lock' keyword is effectively short-hand for something more verbose.  See here for details on the lock statement.  Lock resolves down to Monitor.Enter() [plus some more stuff].  If you want to attempt to lock something, but detect if it is already locked and then not perform that action instead, use TryEnter.   ;  So if using the tryenter for a non blocking attempt to lock dataBuffer, would it look something like this?if (TryEnter(dataBuffer)){  read and remove data from dataBuffer}so would this only execute the read and remove part if the lock was successful?