Counterpart of the 'synchronized' java keyword?

[master]

As far as I understand, 'lock' is the only option, isn't it?

Namely, If I want to declare a 'synchronised' method, I do it this way:

class A {

void AMethod() {
lock (this) {
// the method body
}
}

}

Am I right?

DW

[Nicholas Paldino [.NET/C# MVP]]

DW,

Yes, that is how you do it, although you can choose different objects to
lock on other than "this".

You can also attach the MethodImpl attribute to the method, like so:

class A
{
[MethodImpl(MethodImplOptions.Synchronized)]
void AMethod()
{
}
}

This has the same effect as locking the method on "this".

Hope this helps.

"master" <ma****@master.com> wrote in message
news:OZ**************@TK2MSFTNGP02.phx.gbl...

As far as I understand, 'lock' is the only option, isn't it?

Namely, If I want to declare a 'synchronised' method, I do it this way:

class A {

void AMethod() {
lock (this) {
// the method body
}
}

}

Am I right?

DW

[Tom Spink]

master wrote:

As far as I understand, 'lock' is the only option, isn't it?

Namely, If I want to declare a 'synchronised' method, I do it this way:

class A {

void AMethod() {
lock (this) {
// the method body
}
}

}

Am I right?

DW

Hi DW,

Yes.

--
Hope this helps,
Tom Spink

[master]

> You can also attach the MethodImpl attribute to the method, like so:

[MethodImpl(MethodImplOptions.Synchronized)]
void AMethod()

Thanks, I did not know about it.

DW

[Andy]

Hi,

Do not ever lock on 'this', always create an object which is private to
your class, and lock on that.

The reason is that client code may have locked on the instance which
'this' represents, so if you lock on 'this' as well, you'll end up in a
deadlock.

HTH
Andy

master wrote:

You can also attach the MethodImpl attribute to the method, like so:

[MethodImpl(MethodImplOptions.Synchronized)]
void AMethod()

Thanks, I did not know about it.

DW

[Nicholas Paldino [.NET/C# MVP]]

That's not really an accurate way of indicating why you don't lock on
"this".

While it is true that exposing "this" can contribute to deadlocks, it's
a very small reason. Deadlocks are more an issue that arises when there is
a coupling between objects and the order of operations is not defined
clearly. Deadlocks can certainly arise with using internal objects which
are private as locks. It's not an issue specific to exposing "this".

Ultimately, the reason you do not want to expose "this" is that it is
exposing an implementation detail, which is private. Just like you don't
expose fields which are the backing for properties, you don't expose this.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Andy" <aj*****@alum.rit.edu> wrote in message
news:11**********************@p79g2000cwp.googlegr oups.com...

Hi,

Do not ever lock on 'this', always create an object which is private to
your class, and lock on that.

The reason is that client code may have locked on the instance which
'this' represents, so if you lock on 'this' as well, you'll end up in a
deadlock.

HTH
Andy

master wrote:

> You can also attach the MethodImpl attribute to the method, like
> so:
>
> [MethodImpl(MethodImplOptions.Synchronized)]
> void AMethod()

Thanks, I did not know about it.

DW

[Andy]

'this' is a special keyword which refers to the instance of the class
which is executing the instance code. You can't expose 'this' since
the client already has a reference to the object anyway. So its not
'exposing implementation detail', since the client code has no way of
knowing what you're really locking on (short of decompling your
assembly).

Its true you can have deadlocks within your code without locking on
this; I never said that you couldn't. The point is that you have
control over your own class, and thus know exactly what you're locking
on and can fix it.

What you may not have control over is the client code using your class;
that code may decide to lock on your instance of the object, then call
a method which locks on 'this' That will create a deadlock. This is
especially bad if your code happens to be a library you're selling,
because it will seem as if your library is broken.

You don't have to take my word for it though, this is straight from
MSDN:
"Generally, it is best to avoid locking on a public type, or on object
instances beyond the control of your application. For example,
lock(this) can be problematic if the instance can be accessed publicly,
because code beyond your control may lock on the object as well. This
could create deadlock situations where two or more threads wait for the
release of the same object. Locking on a public data type, as opposed
to an object, can cause problems for the same reason. Locking on
literal strings is especially risky because literal strings are
interned by the common language runtime (CLR). This means that there is
one instance of any given string literal for the entire program, the
exact same object represents the literal in all running application
domains, on all threads. As a result, a lock placed on a string with
the same contents anywhere in the application process locks all
instances of that string in the application. As a result, it is best to
lock a private or protected member that is not interned."

ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.VisualStudio.v80.en/dv_csref/html/413e1f28-a2c5-4eec-8338-aa43e7982ff4.htm

No where does it say that locking on this is bad because it exposes
implementation detail (it doesn't, unless the person using your code
figures out why calling certain methods is deadlocking their
application).

Also, please do NOT send me email replies; keep all replies to me on
the thread only.

Thanks
Andy
Nicholas Paldino [.NET/C# MVP] wrote:

That's not really an accurate way of indicating why you don't lock on
"this".

While it is true that exposing "this" can contribute to deadlocks, it's
a very small reason. Deadlocks are more an issue that arises when there is
a coupling between objects and the order of operations is not defined
clearly. Deadlocks can certainly arise with using internal objects which
are private as locks. It's not an issue specific to exposing "this".

Ultimately, the reason you do not want to expose "this" is that it is
exposing an implementation detail, which is private. Just like you don't
expose fields which are the backing for properties, you don't expose this.

[Marc Gravell]

>What you may not have control over is the client code using your class;

that code may decide to lock on your instance of the object, then call
a method which locks on 'this' That will create a deadlock.

Not by itself it won't; most common locks are re-entrant, so this will work
fine without deadlocking; you need two threads for a "lock" deadlock to
occur, and (for instance) both threads to be locking on a pair of objects in
a different sequence.

However - to emphasise, I agree 100% with your point: any public class that
locks on "this" is just a ticking bomb, waiting for somebody else to lock on
you. Not to be recommended.

Marc

[master]

Then...

Is

[MethodImpl(MethodImplOptions.Synchronized)]
void AMethod()

better than:
[MethodImpl(MethodImplOptions.Synchronized)]
void AMethod() {
lock (<anything>) {
}
}

???

DW

[Marc Gravell]

Not better; different; wose in a few cases...

By using [MethodImpl(MethodImplOptions.Synchronized)], you have no control
over what the locking object /is/. Two issues come to mind:

a: you have several disparate methods that do different things; methods A,
B, C lock on X, and D, E lock on Y; you can't do that cleanly with
MethodImpl

b: to avoid deadlocks you need (for instance) to lock on your parent
*before* you lock locally; can't do that with MethodImpl

c: unless you are absolutely sure what the lock object is, you can't use
Monitor.Pulse, Monitor.Wait etc to communicate; if MethodImpl locks against
"this" (and I can't remember, 'cos I don't use
MethodImplOptions.Synchronized), then you might be able to get away with
Pulse(this), but personally I would prefer to be able to /see/ the lock(obj)
statement before I Pulse(obj).

I personally think explicit lock statements are much clearer to follow;
people sometimes say it is more work, which I don't get as
"lock(SyncLock){}" isn't much typing... each to their own.

Marc

[master]

I have some problem in understanding what actually lock(something) means.

Does lock(something) {...} mean, that during the execution of {...} any
thread accessing the object something will wait until the block is finished?

For example:

Hashtable ht = new Hashtable();
....
lock ( ht ) {
ht["1"] = "1"; // 1
ht["2"] = "2"; // 2
}

Is it possible for another thread to access ht between the statements 1 and
2 and (for example) determine that it has only one key?

DW