Re: Threads - why isn't a whole object locked when ...?
- From: "Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Sat, 24 Jan 2009 20:55:27 -0800
On Sat, 24 Jan 2009 18:11:47 -0800, <beginwithl@xxxxxxxxx> wrote:
Uh, I don’t get it. I’m prob way off with this --> You mean if I have
a public method A_m1 ( in object A1 ) and I use “this” reference for a
lock inside A_m1, then outside code may at the same time use a
reference to A1 on a lock inside some other method ( which may very-
well be defined in some other class )?
If that is what you guys meant ( which I highly doubt ), then why
would that cause a dead-lock?
That's exactly what I meant. As Arne says, it's not guaranteed to cause dead-lock. You still need another lock, taken in a different sequence from the code using the "this" reference as the locking object. The point is that if you keep your locking object private, then you _know_ no other code is going to try to use it for locking.
Doing that doesn't even guarantee there won't be dead-lock. If there's poorly written code elsewhere, there's always the possibility they'll find some other way to create a dead-lock. It's just that using the "this" reference means you're basically leaking part of your synchronization implementation, and it's never a good idea to leak implementation. In this case, leaking implementation makes it a lot easier for dead-lock to occur.
[...]Which object you use for locking has nothing to do with what you protect
with the lock statement.
I thought it does in cases where object used for locking is also
object the code inside the lock statement is operating on
Nope. There's nothing special about the "this" reference versus any other reference. It's used exactly in the same way.
(Note: that's not strictly speaking true. In particular, there are some places where the "this" reference gets used implicitly for locking -- such as default event implementations and there's a code attribute that synchronizes an entire method and which uses "this" -- but even those cases still wind up implicitly using "this" in the same way that any other reference would be used).
[...]No, that doesn't really make sense as you can't lock an object. If youWhat would be the best way to protect that data? If you pass some
pass some data into a method that uses a lock, it's up to the method to
protect that data also.
object O of type T into a method, then only way you can protect O
( while code in a method is operating on it), is that you somehow make
sure there is no other method ( defined in this or any other class )
operating on that data at the same time.?!
Now since you can’t lock O, I’m not sure how you would manage to
protect it ( assuming some third party created type T and also
assuming app also has some third-party objects that also can operate
on O )?!
You can only protect data in the same cooperative way any synchronization occurs. Don't read too much into the word "protect" in this context. The data is protected only insofaras you correctly synchronize all access to the data.
Pete
.
- References:
- Threads - why isn't a whole object locked when ...?
- From: beginwithl
- Re: Threads - why isn't a whole object locked when ...?
- From: Peter Duniho
- Re: Threads - why isn't a whole object locked when ...?
- From: beginwithl
- Threads - why isn't a whole object locked when ...?
- Prev by Date: tough question on xps (microsofts pdf)
- Next by Date: Re: Magazine Visual C# - Programming for beginners
- Previous by thread: Re: 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
|
