SyncLock (Lock)

[Steven Spencer \(Spinalogic\)]

Hey guys.

I come from a Java background and I'm familiar with monitors in java.

I ahve been reading about the .net monitors, including the Lock loops, and I
came across a question.

In most .net examples, there is a specific object (usually just of type
object) upon which the CLR creates the monitor and it is this object is used
to ensure no concurrency.

For instance if I was using something in the collections class, in java I
would just lock on the queue/list/array/map etc to ensure thread safe
access. Why is it that the majority of examples use a separate object?

 

[William Stacey [C# MVP]]

As you know, you can use any object as long as you always use the same
object. You last question is interesting. A lot of times your code and
contained collections change, rename, etc. At least for me, sometimes it is
just easier to define "private readonly object syncRoot = new object()"
upfront and know it will always be your syncRoot regardless of changes to
collections. Also, sometime you may have finer grain locking going on. So
you may be locking on a collection for a different reason. However, there
is nothing wrong with locking on your list object if that is the only lock
you need and your never replace your list object with another latter in your
program. What every it is - make it readonly!

--
William Stacey [C# MVP]

message | Hey guys.
|
| I come from a Java background and I'm familiar with monitors in java.
|
| I ahve been reading about the .net monitors, including the Lock loops, and
I
| came across a question.
|
| In most .net examples, there is a specific object (usually just of type
| object) upon which the CLR creates the monitor and it is this object is
used
| to ensure no concurrency.
|
| For instance if I was using something in the collections class, in java I
| would just lock on the queue/list/array/map etc to ensure thread safe
| access. Why is it that the majority of examples use a separate object?
|
|

 

[Steven Spencer \(Spinalogic\)]

It depends on the scenario.

Monitors are great at abstracting the semaphore code, not to mention that
the CLR itself is the one who controls the monitor, I believe that the java
semaphore classes were flawed as the runtime didn't directly control them,
hence the introduction of monitors.

I can understand from your coding point of view that using a diff object
would be good, but I was just wondering if there was a technical reason for
why you *Shouldn't obtain an object lock on a variable within your code.

I take it you make the object reference read only to ensure that the
reference to the object holiding the monitor is not lost and thus all
concurrency protection as well?

 

[Barry Kelly]

For instance if I was using something in the collections class, in java I
would just lock on the queue/list/array/map etc to ensure thread safe
access. Why is it that the majority of examples use a separate object?

I think the cultural reason for using a different object is, when
avoiding using 'this' (which is of course a deadlock risk), a specific
private surrogate object is created to take its place.

It's also often used for atomic updates of more than one object / object
graph, to avoid ambiguity about which object is the "main" object for
such an atomic update.

-- Barry

 

[Steven Spencer \(Spinalogic\)]

That makes sense.

I think the cultural reason for using a different object is, when
avoiding using 'this' (which is of course a deadlock risk), a specific
private surrogate object is created to take its place.

It's also often used for atomic updates of more than one object / object
graph, to avoid ambiguity about which object is the "main" object for
such an atomic update.

-- Barry

 

[Jon Skeet [C# MVP]]

I come from a Java background and I'm familiar with monitors in java.

I ahve been reading about the .net monitors, including the Lock loops, and I
came across a question.

In most .net examples, there is a specific object (usually just of type
object) upon which the CLR creates the monitor and it is this object is used
to ensure no concurrency.

For instance if I was using something in the collections class, in java I
would just lock on the queue/list/array/map etc to ensure thread safe
access. Why is it that the majority of examples use a separate object?

See http://www.pobox.com/~skeet/csharp/threads/lockchoice.shtml

Note that exactly the same arguments hold in Java too.

 

[William Stacey [C# MVP]]

| Monitors are great at abstracting the semaphore code, not to mention that
| the CLR itself is the one who controls the monitor, I believe that the
java
| semaphore classes were flawed as the runtime didn't directly control them,
| hence the introduction of monitors.

Hmm. Not sure about Java, but in .Net, Monitors are Monitors and Semephores
are Semaphores. Semaphores where added to framework in 2.0.

| I can understand from your coding point of view that using a diff object
| would be good, but I was just wondering if there was a technical reason
for
| why you *Shouldn't obtain an object lock on a variable within your code.

No techinical reason I can think of as long as code is correct. As others
said, there are some fair arguments to use a seperate object.

| I take it you make the object reference read only to ensure that the
| reference to the object holiding the monitor is not lost and thus all
| concurrency protection as well?

yes.
--wjs

 

[Steven Spencer \(Spinalogic\)]

What I mean is the Semaphore class was inherently flawed due to its
implementation as code in the runtime.

Monitors and Semaphores in Java are different. A monitor is effectively a
size one semaphore, just that the CLR controls access to the monitor meaning
that it is GUARANTEED thread safe, no obscure situation could exist where
the semaphore could be accessed incorrectly.

I take it that before .net 2.0 if you needed a semaphore you hit up the
Kernel32.dll and got one from there? That would be fairly slow though
wouldn't it?