当前位置: 代码迷 >> .NET Framework >> Concurrent Synchronizer Framework(二)
  详细解决方案

Concurrent Synchronizer Framework(二)

热度:159   发布时间:2016-05-02 00:07:13.0
Concurrent Synchronizer Framework(2)

?

这章来自3.1《Synchronization State》和3.2的《Blocking》。

AbstractQueuedSynchronizer会维护一个Int类型的synchronization state。公开了3个访问和更新state的方法,分别是:getState,setState和compareAndSetState。这些方法依赖java.util.concurrent.atomic和volatile。其中compare-AndSetState实现是依赖于CAS(compare-and-swap)或LL/SC(loadlinked/store-conditional)。CAS大家可能比较熟悉,(current ==expect)则设值。LL/SC则比CAS更严格,(current==expect && current 没有被restore)才算竞争成功。current被restore仍然等于current,CAS是竞争成功的。这是ABA问题。是否觉得LL/SC有点AtomicStampedReference的味道?的确,AtomicStampedReference是通过引进版本号来检测是否被restore。

??????? 用一个32位的int来表示synchronization state是一个实用的决定,虽然jsr166提供了64位的long的原子操作,但在一些平台上需要实用内部锁来实现,对性能有所影响。在未来可能引入一个用long来表示synchronization state的基类,但在现在还没有一个足够的理由把这个类包含进来。而且32位的state也满足了大部分应用的需要。只有一个synchronizer CyclicBarrier看起来需要更多的位来表示state。


??????? 继承于AbstractQueuedSynchronizer的具体类必须明确的定义tryAcquiretryRelease方法,用来控制acquire和release操作。如果synchronization 被获取,tryAcquire必须返回true。如果新的synchronization? state允许以后的acquire,tryRelease也必须返回true。这些方法提供一个int的参数来表示希望的state。例如在一个可重入锁里,就需要计数,但对于大多数的synchronizer是可以忽略这个参数的。


在jsr166前,如果不基于嵌入的monitor,是没有可用的java api去block和unblock一个线程的。唯一的候选方法是Thread.spspend和Thread.resume。但是它们不符合要求,原因是:如果一个unblocking的线程在调用suspend被阻塞前调用了resume是没有效果的(这里是希望,如果在调用suspend前resume先被调用,suspend不会导致线程挂起)。

在并发包里包含了一个LockSupport的类,该类解决了这个问题。方法LockSupport.park会block当前线程,除非或直到LockSupport.unpark被调用。unpark的调用是不会被计数的,所以多次unpark只会影响之后的第一次park。然后这些应用是针对每个thread的,而不是每个synchronizer。一个thread在一个新的synchronizer调用了park可能马上返回,因为unpark在之前被调用了。如果没有unpark,那么下次调用park就会导致thread阻塞。可能会需要一个操作去清理thread 的state,使park可以阻塞thread,但是其实不需要这么做,在需要的情况下,多调用几次park更高效。



在某些程度上,这个简单的原理看上去和某些平台的某些机制很相像,例如在Solaris-9的thread library,windows的“consumeable events”,Linux NPTL thread library。park和unpark可以高效的映射到这些常见的支持jvm的平台上。park也支持相对和绝对的超时时间,并且可以和Thead.interrupt结合,interrupt一个thread可以unpark它。

?


?

?

?

  相关解决方案