What's great about C#
-
The
lockstatement, dude. Writing Multithreaded code never was so much fun.
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygen -
wayward wrote: As long as its not "lock (typeof(Foo))"... And as long as it's not lock (string.Empty) And as long as it's not lock (this) And as long as it's not lock (someStringConstant) and you use string pooling (Release Build) and you happen to have two equal string constants on your code (you'll lock the same object). Actually, I found that the most safe and reliable object to lock is always some string constant which have each a different value, a unique GUID.
// Quantum sort algorithm implementation
while (!sorted)
; -
wayward wrote: As long as its not "lock (typeof(Foo))"... And as long as it's not lock (string.Empty) And as long as it's not lock (this) And as long as it's not lock (someStringConstant) and you use string pooling (Release Build) and you happen to have two equal string constants on your code (you'll lock the same object). Actually, I found that the most safe and reliable object to lock is always some string constant which have each a different value, a unique GUID.
// Quantum sort algorithm implementation
while (!sorted)
;Hmm.. how can these points be any problems?
lockis surely aware of the calling thread, and will thus not block the thread who acquired the lock?? -- Gnnnnmmmpppppppfffffhhh! -
The
lockstatement, dude. Writing Multithreaded code never was so much fun.
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygenYep, for me when I first used it was the static constructor. Makes it easier to write clean code.
"Je pense, donc je mange." - Rene Descartes 1689 - Just before his mother put his tea on the table. Shameless Plug - Distributed Database Transactions in .NET using COM+
-
wayward wrote: As long as its not "lock (typeof(Foo))"... And as long as it's not lock (string.Empty) And as long as it's not lock (this) And as long as it's not lock (someStringConstant) and you use string pooling (Release Build) and you happen to have two equal string constants on your code (you'll lock the same object). Actually, I found that the most safe and reliable object to lock is always some string constant which have each a different value, a unique GUID.
// Quantum sort algorithm implementation
while (!sorted)
; -
?? :~
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygenThere is an article on the Microsoft website about how this is a really bad thing to do as it can cause all sorts of problems within the .NET runtime - including the inability to create new objects of that type whilst the lock is being held. I know its in the examples, but they say they will be revising them in the future... James.
-
wayward wrote: As long as its not "lock (typeof(Foo))"... And as long as it's not lock (string.Empty) And as long as it's not lock (this) And as long as it's not lock (someStringConstant) and you use string pooling (Release Build) and you happen to have two equal string constants on your code (you'll lock the same object). Actually, I found that the most safe and reliable object to lock is always some string constant which have each a different value, a unique GUID.
// Quantum sort algorithm implementation
while (!sorted)
; -
a) you can even lock on string.Empty?? who would want to do that? b) what#s so bad about lock(this) and lock(typeof(foo)) ?
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygenpeterchen wrote: you can even lock on string.Empty?? who would want to do that? Unfortunately, I see lots of people doing this. peterchen wrote: what#s so bad about lock(this) Your object cannot be used for a lock, or you'll risk a deadlock. Instead of doing it, create a private field and use lock(privateField). peterchen wrote: and lock(typeof(foo)) ? Because it's the same as lock(foo.GetType()), which happens to return a cached value, so you again risk a deadlock. "Oh, I know what I am doing" - Yes, but the one who consumes your class sometimes don't. The rule is: always lock on a private field or a private static field, and if it is a string, make sure it is unique on the entire assembly.
// Quantum sort algorithm implementation
while (!sorted)
; -
peterchen wrote: you can even lock on string.Empty?? who would want to do that? Unfortunately, I see lots of people doing this. peterchen wrote: what#s so bad about lock(this) Your object cannot be used for a lock, or you'll risk a deadlock. Instead of doing it, create a private field and use lock(privateField). peterchen wrote: and lock(typeof(foo)) ? Because it's the same as lock(foo.GetType()), which happens to return a cached value, so you again risk a deadlock. "Oh, I know what I am doing" - Yes, but the one who consumes your class sometimes don't. The rule is: always lock on a private field or a private static field, and if it is a string, make sure it is unique on the entire assembly.
// Quantum sort algorithm implementation
while (!sorted)
; -
Actually, there is a very good use of "lock(stringConst)" - when you have a multithreaded cache and only want to lock the portion on the cache (or key) you are about to update... James.
wayward wrote: Actually, there is a very good use of "lock(stringConst)" - when you have a multithreaded cache and only want to lock the portion on the cache (or key) you are about to update... I think you misunderstood: This is good practice, indeed. Just make sure the stringConst contains a unique string or you may face a deadlock - only on Release builds.
// Quantum sort algorithm implementation
while (!sorted)
; -
Daniel Turini wrote: or you'll risk a deadlock why? (link would be enough)
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygenpeterchen wrote: why? (link would be enough) I have no link to this. Just as a sample, imagine a class A & B where class A.someMethod(B b) does:
lock(this)
{
b.SomeMethod();
}And b.SomeMethod() does:
lock(this)
{
....
}Reasonable, huh? This will work, until someone who calls it, do:
B b = new B();
lock (B)
{
}In another thread and use the same b to A.someMethod(). Believe me, this really happens in the real world and it's hard to find it. You can avoid all of this hassle with two very simple rules: 1. Always lock your own private fields (static or not, depending on the case). 2. If you lock strings, always use unique strings.
// Quantum sort algorithm implementation
while (!sorted)
;