ReaderWriterLock

  • Thread starter Thread starter Itay
  • Start date Start date
I

Itay

Hi ,

Is there a way to lock several ReaderWriterLock in an atomic manner?
I have numerous amount of ReaderWriterLock objects and I need to lock
some of them for reading only, is there a way doing it one shot ?

Itay.
 
Hi Itay:

I don't know a way to do it in one shot. Can you guarantee the code
will always acquire locks in the same order?
 
Scott Allen said:
Hi Itay:

I don't know a way to do it in one shot. Can you guarantee the code
will always acquire locks in the same order?
Click to expand...


Suppose i can , how can it be helpfull ?
Do you suggest looping over the lockers ? doesn't it invites a deadlock ?
 
Hi Itay:

In general, if you have multiple locks to acquire then as long as
everyone acquires them in the same order you can avoid deadlock.

For example, let's say I have multiple locks to acquire: locks A, B,
and C. I'd establish a rule that says no code can acquire lock C
without first acquiring lock B, and no code can acquire lock B without
first acquiring lock A. This prevents the scenario where a thread has
lock B and needs lock A, and another thread has lock A and needs lock
B.

If you have a collection of locks you can loop through them and
acquire each in turn. As long as all the code follows the same
protocol by looping in the same order, acquiring each in turn, there
will be no problems.

The correct locking order is often referred to as a 'lock hierarchy'
in MT circles. The classic trade off is that you are probably trying
to implement a fine grained locking mechanism, and a lock hierarchy
invariably pushes the design back to doing more coarse grained
locking, so it's a very delicate balance to find. It's usually best to
start with a simple coarse grained locking mechanism, then measure
performance and move to a more complicated solution only if necessity
requires it.
 
I would be interested if anyone knows, what kind of synchronization
mechanisms are used for distributed computing using .Net.

For instance, User level vs. Kernel level on distributed computers. I
read about something called Test & Set. Is that used by .Net?

Thanks.
 
The classic trade off is that you are probably trying
to implement a fine grained locking mechanism, and a lock hierarchy
invariably pushes the design back to doing more coarse grained
locking, so it's a very delicate balance to find. It's usually best to
start with a simple coarse grained locking mechanism, then measure
performance and move to a more complicated solution only if necessity
requires it.
Click to expand...

So true Scott. You can get bound up in a nest of locks and your
thread-lock-bug matrix expands like my stomach at Thanksgiving. I went down
the fine grain lock for a memory based object db thing I was doing and went
back and forth a couple times. In the end, I found one lock was better then
anything else I could come up with. Especially, when you concider other
"Users" for your DB like WebServices, etc. Some API may want to iterate
over your collection(s), some update, and some read. Also remember that RW
locks are a lot slower then monitors, so you need to factor in the
cost/benefits of that. You may be able to service 3+ Monitor requests for
every one (need to test) RW lock and add multiple RW or monitor locks and
things get a bit slower still. Also, the more locks you need to
grab...well, the more locks you need to grab - and they are not free. So
fewer towards one "may" be better depending. Also, you may want to look at
a larger thread picture. How many threads do you actually need? Are you
sure you need that many? Is it making your app more responsive (i.e. more
requests per second) or slower? How much blocking is going on inside the
APIs? Maybe only one thread needs to touch the db at any one time and all
requests are serviced from a blocking circular queue so no lock may even be
required (cq will still need one lock) - this method has a lot to love about
it - but depends on your design and needs. Interesting and complex topic.
Cheers.
 
I would be interested if anyone knows, what kind of synchronization
mechanisms are used for distributed computing using .Net.
Click to expand...

The normal lock (i.e. Monitor), rw locks, events, mutexs are all used. The
native win32 mutex, sem, events, etc can still be used but I would typically
not use them unless I needed the "named" versions for cross process
something or other (and I think fw 2.0 has managed wrapper for them now).
For instance, User level vs. Kernel level on distributed computers. I
read about something called Test & Set. Is that used by .Net?
Click to expand...

This basically translates to the Interlocked.CompareExchange (i.e.
Interlocked.CompareExchange, Interlocked.Increment, etc.) The Increment and
Decrement methods are most useful. CompareExchange can be handy if you have
special needs or require very special attention to performance, but more
folks try to stay away from that in favor of standard Monitor symatics. A
major reason is it is easier to "reason" about and prove out the correctness
of your code using locks then using low level Interlocked apis. However, if
you need them, its great to have them. hth.
 
Back
Top