Re: Threads - why isn't a whole object locked when ...?
- From: "Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Sat, 24 Jan 2009 16:59:02 -0800
On Sat, 24 Jan 2009 16:30:31 -0800, <beginwithl@xxxxxxxxx> wrote:
[...]
2) Book suggests that if you are locking down a region of code within
apublic member, it is safer to declare a private object member
variable to serve as a token:
class Printer
{
private object threadLock = new object();
public void PrintNumbers()
{
lock ( threadLock )
{ …}
}
}
Now why would having a public token in a public method represent a
security risk:
It's not a security risk. It's a deadlock risk.
All of your questions are answerable by pointing out that you have an incorrect mental model of what it means to "lock" something. Thread synchronization (which is what the "lock" statement does) does _not_ lock an object at all. It's entirely cooperative between threads, and it's simply a way for multiple threads to coordinate access to shared data, or to synchronize execution of a specific block of code (or both).
One might say that the name of the "lock" statement is misleading. That is, while it's entirely sensible to people who are familiar with standard thread synchronization techniques, in reality it's not actually locking anything. Instead, it's using the reference as a sort of traffic signal for other threads, which are cooperating, to respect.
The "lock" statement passes the given object reference to the Monitor.Enter() method, which has a specific defined behavior in that until you later call Monitor.Leave() or Monitor.Wait() using the same object, no other call to Monitor.Enter() can return. That's all. It has no way of literally locking the entire object. Windows just doesn't provide for that kind of synchronization model (nor do other mainstream platforms, for that matter).
As for the question about using an internal reference instead of the "this" reference, the point of that is that the "this" reference is visible to other code you don't have control over. And if you use "this" to synchronize, there's a risk that some other code might use the same reference to synchronize, resulting in a different, unpredicted code path where the same reference is being used to synchronize. This may lead, at a minimum, to your own code path getting blocked unexpectedly, and in the worst case, could lead to a deadlock scenario where that reference is used in synchronization, along with some other reference as well, but taken in different orders (a classic way to get into deadlock).
Pete
.
- Follow-Ups:
- Re: Threads - why isn't a whole object locked when ...?
- From: beginwithl
- Re: Threads - why isn't a whole object locked when ...?
- References:
- Threads - why isn't a whole object locked when ...?
- From: beginwithl
- Threads - why isn't a whole object locked when ...?
- Prev by Date: Re: Compiler and it’s (in)ability to detect incompatible assignments
- Next by Date: Re: Threads - why isn't a whole object locked when ...?
- Previous by thread: Threads - why isn't a whole object locked when ...?
- Next by thread: Re: Threads - why isn't a whole object locked when ...?
- Index(es):
Relevant Pages
|
