Creating a Shared Lock

[Bob Bins]

Is there a way to create a shared lock using the Monitor class or any other
synchronization class in .NET?

So I have one resource that may have multiple threads using it at once but a
second thread that when called must have exclusive access and cause the
other threads to wait.

I can't figure out how to do this with .Net.

Thanks.

[Vadym Stetsyak]

Hello, Bob!

BB> So I have one resource that may have multiple threads using it at once
BB> but a second thread that when called must have exclusive access and
BB> cause the other threads to wait.

BB> I can't figure out how to do this with .Net.

I believe you can use lock(resource) { } in the thread in order to access that resource.
or you can write wrapper around resource and inside wrapper have lock(resource) { }.

Can you be more specific about what those thread are doing with resource and what is the role of
"second thread"?

--
Regards, Vadym Stetsyak
www: http://vadmyst.blogspot.com

[Brian Gideon]

Bob,

You could use the ReaderWriterLoc k. Using this lock threads that have
acquired a reader lock all get access to the shared resource, but a
thread that acquires a writer lock gets exclusive access.

I usually avoid the ReaderWriterLoc k because it is slower in most
scenarios and more complicated to use correctly. But, I wanted to at
least throw that out here as a possible option.

Brian

Bob Bins wrote:

Is there a way to create a shared lock using the Monitor class or any other
synchronization class in .NET?

So I have one resource that may have multiple threads using it at once but a
second thread that when called must have exclusive access and cause the
other threads to wait.

I can't figure out how to do this with .Net.

Thanks.

[William Stacey [MVP]]

Hi Bob. That is actually what a Monitor if for. Only one thead at a time
can own the lock on the Monitor object and any others will Q waiting for it
to free in ~FIFO order. Each thread must lock on the same object for this
to work.

--
William Stacey [MVP]

"Bob Bins" <ms****@hotmail .com> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..
| Is there a way to create a shared lock using the Monitor class or any
other
| synchronization class in .NET?
|
| So I have one resource that may have multiple threads using it at once but
a
| second thread that when called must have exclusive access and cause the
| other threads to wait.
|
| I can't figure out how to do this with .Net.
|
| Thanks.
|
|

[Bob Bins]

No thats not suffecient. I am writing a test application and I need to
syncronize my database access. I need one funciton to execute at the rate
around 100 times a seconds. This funcation will be called at the same time
from multiple threads. A second thread that is called once every second
needs to lock so the other function does not get called while its running.

In SQL you would do this by creating a shared lock on the first function
then a exclusive lock on the second. This allows many threads to have
shared access but once a thread has an exclusive lock any shared locks will
wait.

It sounds like the ReaderWriterLoc k is what I will need. I didn't even no
that class existed.
"William Stacey [MVP]" <wi************ @gmail.com> wrote in message
news:eN******** ******@tk2msftn gp13.phx.gbl...

Hi Bob. That is actually what a Monitor if for. Only one thead at a time
can own the lock on the Monitor object and any others will Q waiting for
it
to free in ~FIFO order. Each thread must lock on the same object for this
to work.

--
William Stacey [MVP]

"Bob Bins" <ms****@hotmail .com> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..
| Is there a way to create a shared lock using the Monitor class or any
other
| synchronization class in .NET?
|
| So I have one resource that may have multiple threads using it at once
but
a
| second thread that when called must have exclusive access and cause the
| other threads to wait.
|
| I can't figure out how to do this with .Net.
|
| Thanks.
|
|

[William Stacey [MVP]]

| No thats not suffecient.

Not so fast. It can be more efficient then a RW depending of what is really
going on (which may or may not be what you think is going on as you need to
look deeper when dealing with locks).

| I am writing a test application and I need to
| syncronize my database access. I need one funciton to execute at the rate
| around 100 times a seconds. This funcation will be called at the same
time
| from multiple threads. A second thread that is called once every second
| needs to lock so the other function does not get called while its running.
|
| In SQL you would do this by creating a shared lock on the first function
| then a exclusive lock on the second. This allows many threads to have
| shared access but once a thread has an exclusive lock any shared locks
will
| wait.

Monitor allows this. Effectively it is read or write lock but exclusive.
On my laptop I get 10 million locks in 364ms, so contention for the lock is
not going to be your bottle neck unless your holding the lock for a long
time in each "reader" thread. A RW lock is about 5 times slower then a
monitor, so you have to factor that in. You could end up with more
contention and slower overall solution. On a single CPU, there will not be
hardly any contention for the monitor if you can get out of the lock ~within
the thread time slice.

You going to be making DB network calls 100 times a second from multiple
readers? You sure that is even going to scale? If readers hold the lock
for more then 1 second, then your writer(s) are going to block anyway. You
also will have fairness issues. If a reader has the lock, new readers will
get a reader lock, pushing back new writers in time - so you can starve your
writer(s).

Could you instead use a reader queue and just have one reader thread making
requests as fast as possible? Would need to know more about the needs.

| It sounds like the ReaderWriterLoc k is what I will need. I didn't even no
| that class existed.

It may be what you need, but I would be careful. It could also not perform
as expected. A refactor of the design could prove more efficient.