How do you call this kind of concurrency related class? And is there a standard implementation?

Since I 开发者_运维问答couldn't find a standard implementation of it I created this little class, but I think something simple as this should exist somewhere already:

class ReturnValue {
    private var value = false

    private val latch = new java.util.concurrent.CountDownLatch(1)

    def setValue(aValue: Boolean) {
        value = aValue
        latch.countDown()
    }
    def getValue() = {
        latch.await
        value
    }
}

The purpose of it is to exchange a value between two threads (main thread + EDT in my case). From the code using the getValue() method it looks almost like a Future, but the Future implementations I found expect the caller to provide the code to be executed, which doesn't work in my case.

So my questions are:

• Is there a name for such a thingy?
• Is there a standard implementation for it in java or scala?
• Is my implementation even correct?

---

Scala standard library provides this kind of synchronization mechanism as scala.concurrent.SyncVar[T] class.

This Scala REPL session demonstrates how it works:

scala> import concurrent._           
import concurrent._

scala> import ops._                  
import ops._

I am importing ops._ to spawn another Thread easily.

scala> val syncInt = new SyncVar[Int]
syncInt: scala.concurrent.SyncVar[Int] = scala.concurrent.SyncVar@17823918

scala> spawn { println("got %d" format syncInt.get) }

I am spawning another thread. get blocks until there is a value in the syncInt.

scala> syncInt.isSet
res1: Boolean = false

scala> syncInt.set(103)

scala> got 103

The above has been printed by the thread we created before.

scala> syncInt.isSet
res3: Boolean = true

scala> syncInt.get
res4: Int = 103

---

Looks somewhat similar to synchronous queue with one element, where consumer has to wait for producer to offer a value.

---

That looks a bit like an Exchanger to me, except it's more one-sided... have you looked at that? Basically you wouldn't need to worry about what you provided from the "waiting" side, or what you received from the "providing" part.

I agree with you that it looks like a future aside from the "executable" part.

---

I created a very similar thing called a BlockingReference where I needed consumers (one or many) to be able to read the latest value or block until one became available. In essence it is like a single element queue as the producer thread can at any time post a new value and then carry on. It is relevant where the only information that needs to be posted is some kind of status update. I use it mark progress in a multi-threaded content-distribution cache (where one thread downloads content and there are multiple consumers rebroadcasting the downloaded bytes). The main difference to yours is that yours is single use.

This implementation is significantly superior to SynchronousQueue and Exchanger as both of those block the producer thread until a handoff occurs. It is superior to the Scala SyncVar in performance as the producer-thread is implemented without any blocking and in features as it can support multiple consumers. It has been heavily performance optimised.

The Atlassian Concurrency lib is Apache2 licensed and is in our public Maven repo.

---

This is somewhat related to flow programming.