|
Thanks Colin,
Colin Angus Mackay wrote: this could potentially lead to a deadlock.
Could you describe a scenario why expose this as lock object will cause deadlock compared with using private object as lock please?
regards,
George
|
|
|
|
|
well, in my exemple NotPrivateClass , has potentially a public scope : some other class could access it
consider 'this' is an instance of NotPrivateClass (in the code you quoted) : someone else could access to the instance refercenced by this ("public scope is offered").
so if you use 'this' as the locking object , then someone else could do the same .. and that's not ggod .. for the deadlock reason I've given
|
|
|
|
|
Thanks girm,
Could you describe a scenario why expose this as lock object will cause deadlock compared with using private object as lock please?
regards,
George
|
|
|
|
|
Sure...
public class PublicClass1
{
public PublicClass1(){};
public void LockMe1(PublicClass2 aPublicInstance2)
{
lock(this)
{
lock(aPublicInstance2)
{
MessageBox.ShowDialog("no deadlock, great!!");
}
}
}
public class PublicClass2
{
public PublicClass2(){};
}
...
say a thread Y calls :
lock(aPublicInstance2)
{
lock(aPublicInstance1)
{
MessageBox.ShowDialog("no deadlock, great!!");
}
}
another thread X calls :
aPublicInstance1.LockMe1(aPublicInstance2);
Lets say that thread X is actually executing '// ref line (X)'
and thread Y is actually executing '// ref line (Y)'
...no problem...
then X step forward and is now stuck because it cannot acquire the lock :
lock(aPublicInstance2) , since it is already locked by thread Y
But Y is still running and perform a call :
...and then is stuck because it cannot acquire lock on aPublicInstance1 (see 'lock(aPublicInstance1)
') because it is locked by thread X (see lock(this) // ref line (X))
...so X is blocking Y, Y is blocking X : deadlock , no message is displayed
-------------------------
Now if locked object were not publicly availlable X and Y thread would not have been able to
put lock on those objects since they wouldn't have access to it.
...
of course simply not using 'lock(this)' will not garantee you will never have deadlocks : it just limit the risks
regards
Girm
|
|
|
|
|
Wonderful sample, cool Grim!
regards,
George
|
|
|
|
|
If you are using the keyword "this" then most likely something elsewhere has access to that object, the thing that called the method you are in will have a reference to what ever "this" is, for example.
If you want to ensure that the object is threadsafe then exposing the thing you are using to lock (synchronise) isn't a good idea as code you have no control over could attempt to do the same thing by locking the object. If that happens, I'd imagine that it becomes easier to get into a situation where deadlocks can occur. A deadlock is where two bits of code are blocked because the first is waiting for the second to complete, and vice versa. In this scenario neither will complete.
So, if the object uses private objects internally to do the locking then nothing else can access the synchonisation objects and you have better control over how the locking works, and if you do find yourself in a situation where a deadlock occurs you won't have far to look to track down the problem (it will all be in one class).
|
|
|
|
|
Thanks Colin,
I read your reply carefully. Agree and understand most of your points. Just one question,
Colin Angus Mackay wrote: If that happens, I'd imagine that it becomes easier to get into a situation where deadlocks can occur.
Why using internal private object as lock object will reduce chance of deadlock compared with using this object? Could you describe a scenario please?
regards,
George
|
|
|
|
|
George_George wrote: Why using internal private object as lock object will reduce chance of deadlock compared with using this object? Could you describe a scenario please?
Well, if you use a private object then nothing outside the class can access the object. That means that you have full control within the class of how instances of the class are synchronised.
If you use "this", and other code uses the reference to the same object then they can interfere with each other. There isn't much you can do to defend yourself from code that you have not written and have no control over.
|
|
|
|
|
Thanks Colin,
I can understand the situation you described above. But could you show by example why in the similar situation, using this object other than using private member as lock object will be more prone to cause deadlock please? 
A sample will make everything clear.
regards,
George
|
|
|
|
|
How can I create a subclass from a base class by just just inputting the name of the subclass I want to create? I think this uses System.Reflection. Need a working code. Thanks.
modified on Saturday, March 22, 2008 9:09 AM
|
|
|
|
|
Use Assembly.CreateInstance[^] to create an instance of a type based on a string representing the name of the type.
Paul Marfleet
"No, his mind is not for rent
To any God or government"
Tom Sawyer - Rush
|
|
|
|
|
how to search particular word from the site using .net with c#
|
|
|
|
|
The most obvious way would be to use google.
Christian Graus - Microsoft MVP - C++
"also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
|
|
|
|
|
Thank you .but I want do to our own search from my own web site. It is possible.
|
|
|
|
|
Yes, of course it is. You'd have to have no dynamic pages, and store all your pages in a SQL Server database. Or, you'd have to write your own search engine that indexes all your pages.
Christian Graus - Microsoft MVP - C++
"also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
|
|
|
|
|
Hello everyone,
What means "the synchronizing object can double as the object it's protecting" in below statements about synchronization object choosing?
I quote the whole paragraph,
http://www.albahari.com/threading/part2.html
--------------------
Choosing the Synchronization Object
Any object visible to each of the partaking threads can be used as a synchronizing object, subject to one hard rule: it must be a reference type. It’s also highly recommended that the synchronizing object be privately scoped to the class (i.e. a private instance field) to prevent an unintentional interaction from external code locking the same object. Subject to these rules, the synchronizing object can double as the object it's protecting, such as with the list field below:
class ThreadSafe {
List <string> list = new List <string>();
void Test() {
lock (list) {
list.Add ("Item 1");
...
--------------------
thanks in advance,
George
|
|
|
|
|
You have a synchronising object, the object used in the lock statement. You also have the object you are protecting with the lock. The statement means that the object you use in the lock statement can be the same as the object you are protecting.
Does that help?
|
|
|
|
|
Thanks Colin!
I think you metn the "list" object is the synchronising object. But what do you mean "the object you are protecting with the lock", you mean also the list obejct which we are going to make it thread-safe?
regards,
George
|
|
|
|
|
George_George wrote: I think you metn the "list" object is the synchronising object
In the example the "list" object is the synchronising object.
George_George wrote: But what do you mean "the object you are protecting with the lock", you mean also the list obejct which we are going to make it thread-safe?
In the example, yes, it will be the list object also.
The example was showing that the object used in the lock, the list, can be the same as the object that is being protected, which is again the list.
|
|
|
|
|
Thanks Colin,
Question answered.
regards,
George
|
|
|
|
|
i want search word in particular web address,so i want to use UltimateSearchInput button,but i didnot know how to use. if u know the code replay to me...
|
|
|
|
|
Hello everyone,
From the sample,
http://www.albahari.com/threading/part2.html
Do you know what means "A thread can block only on the first, or outermost lock."?
I quote the related context below as well.
--------------------
Nested Locking
A thread can repeatedly lock the same object, either via multiple calls to Monitor.Enter, or via nested lock statements. The object is then unlocked when a corresponding number of Monitor.Exit statements have executed, or the outermost lock statement has exited. This allows for the most natural semantics when one method calls another as follows:
static object x = new object();
static void Main() {
lock (x) {
Console.WriteLine ("I have the lock");
Nest();
Console.WriteLine ("I still have the lock");
}
Here the lock is released.
}
static void Nest() {
lock (x) {
...
}
Released the lock? Not quite!
}
A thread can block only on the first, or outermost lock.
--------------------
thanks in advance,
George
|
|
|
|
|
George_George wrote: Do you know what means "A thread can block only on the first, or outermost lock."?
It means that when it encounters the first lock (or outermost lock) the thread blocks others from accessing the object that is locked.
An individual thread can lock an object as many times as it likes, but it only locks on the first occurrence.
|
|
|
|
|
Thanks Colin,
Two more comments,
1.
Colin Angus Mackay wrote: It means that when it encounters the first lock (or outermost lock) the thread blocks others from accessing the object that is locked.
Even if the thread can not acquire the outermost lock, it will block other thread from accessing the lock object to try to lock?
2.
Colin Angus Mackay wrote: An individual thread can lock an object as many times as it likes, but it only locks on the first occurrence.
It is a typo, "only locks on the first occurrence" should be "only blocks on the first occurrence"?
regards,
George
|
|
|
|
|
George_George wrote: Even if the thread can not acquire the outermost lock, it will block other thread from accessing the lock object to try to lock?
It hast to aquire the lock first. If it can't aquire the lock, it can't block.
George_George wrote: It is a typo
Yes. You are correct.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
