| 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 ReaderWriterLock 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.