Synchronized collections
-
Hello, Please someone explain to me which is the need of Sychronized and SyncRoot in .NET collections. Why and how should I use this two features. Aren't the collections thread safe?? And if them aren't, a lock is not enough? Really, I think I have a big missunderstood about collections, please help.:(( Thanks, Miguel
-
Hello, Please someone explain to me which is the need of Sychronized and SyncRoot in .NET collections. Why and how should I use this two features. Aren't the collections thread safe?? And if them aren't, a lock is not enough? Really, I think I have a big missunderstood about collections, please help.:(( Thanks, Miguel
I'm not expert here, but here is my understanding. I believe most of the collections have the SyncRoot element, and when you are locking the collections you need to lock the SyncRoot element. So if you are locking a hastable, it should look something like lock(myhashtable.SyncRoot). The locking keyword in c# is a bit misleading, actually what it does is grant you access to the lock, so that no other thread can acquire the lock until you release it. regards Kannan
-
Hello, Please someone explain to me which is the need of Sychronized and SyncRoot in .NET collections. Why and how should I use this two features. Aren't the collections thread safe?? And if them aren't, a lock is not enough? Really, I think I have a big missunderstood about collections, please help.:(( Thanks, Miguel
Don Miguel wrote: which is the need of Sychronized Synchronized tells you if the collection's operations will be thread-safe. Generally this is done by implementing a wrapper around the collection, using a lock on the SyncRoot for each operation performed. Don Miguel wrote: which is the need of SyncRoot SyncRoot is for doing your own locking. Say you need to add a lot of items to the collection, during which no other thread should use it. Rather than using the Synchronized wrapper which would lock/unlock for each operation you would create a lock on the SyncRoot object, then perform each of your operations. Don Miguel wrote: Aren't the collections thread safe?? No, you need to refer to the documentation for each class you wish to use to find out if the operations are thread-safe. Making everything thread-safe by default is expense CPU wise, so you are better off not putting it in for the cases where thread-safety isn't an issue. Most collection classes expose some way of getting a Synchronized version, usually by a static method of some sort. Always check the documentation to be sure. James "It is self repeating, of unknown pattern" Data - Star Trek: The Next Generation
-
Don Miguel wrote: which is the need of Sychronized Synchronized tells you if the collection's operations will be thread-safe. Generally this is done by implementing a wrapper around the collection, using a lock on the SyncRoot for each operation performed. Don Miguel wrote: which is the need of SyncRoot SyncRoot is for doing your own locking. Say you need to add a lot of items to the collection, during which no other thread should use it. Rather than using the Synchronized wrapper which would lock/unlock for each operation you would create a lock on the SyncRoot object, then perform each of your operations. Don Miguel wrote: Aren't the collections thread safe?? No, you need to refer to the documentation for each class you wish to use to find out if the operations are thread-safe. Making everything thread-safe by default is expense CPU wise, so you are better off not putting it in for the cases where thread-safety isn't an issue. Most collection classes expose some way of getting a Synchronized version, usually by a static method of some sort. Always check the documentation to be sure. James "It is self repeating, of unknown pattern" Data - Star Trek: The Next Generation
Many thanks James! You was very explicit, it helps me much. Don Migule