0

我对RentrantReadWriteLock的理解是，它允许同时读取很多次但只允许一次写入。

当我们尝试获取读锁时，文档状态

Acquires the read lock if the write lock is not held by another thread and returns immediately.

If the write lock is held by another thread then the current thread becomes disabled 
for thread scheduling purposes and lies dormant until the read lock has been acquired.

这里是什么held意思？

  • 另一个线程请求了写锁并且执行比写？

或者

  • 上述情况以及另一个线程已请求写锁但正在等待获取它的情况。

因为当请求写锁时，如果

  • 别人有写锁
  • 别人有读锁

从写锁定文档：

Acquires the write lock if neither the read nor write lock are held by another 
thread and returns immediately, setting the write lock hold count to one.

...

If the lock is held by another thread then the current thread becomes 
disabled for thread scheduling purposes and lies dormant until the write lock has 
been acquired, at which time the write lock hold count is set to one.

因此，当一个线程在请求​​它之后等待写锁时，我只想了解读取锁调用的后续行为。他们是否让写锁的请求等待更长的时间？

4

2 回答 2

1

在这种情况下保持意味着锁已被请求和提供。如果您只是在等待，则不认为已持有。

ReentrantReadWriteLock当大量线程请求锁定时，存在已知问题。Heinz Kabutz 博士与他们一起制作了一篇关于锁饥饿的有趣通讯。

我知道新的 Java 7 Phaser已经解决了许多这些问题，但我还不够熟悉它，无法以一种或另一种方式说。

于 2013-03-30T17:14:48.090 回答
0

是什么意思？

lock has been requested AND acquired.

So when a thread is waiting for a write lock after requesting it, I just want to get an idea of subsequent behaviour of invocations for read locks. Do they make the request for the write lock wait even longer or not?

If at some stage all your read locks have been released a call to lock.writeLock().lock() will succeed in acquiring the write lock. Note however that more than one thread can hold the read lock - so if you have one thread or more holding the read lock at all time, no other thread will be able to acquire the write lock and you will have a serious liveness issue.

于 2013-03-30T17:30:56.223 回答