What do you call this concurrency class a related class? And is there a standard implementation?

Since I could not find a standard implementation, I created this small class, but I think something is simple, since it 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 goal is to exchange the value between the two threads (main thread + EDT in my case). From the code using the getValue () method, it looks almost like the Future, but the expectations found in the future implementation expect the caller to provide executable code that does not work in my case.

So my questions are:

  • Is there a name for such a thing?
  • Is there a standard implementation for it in java or scala?
  • Is my implementation even correct?
+4
source share
5 answers

The Scala standard library provides such a synchronization mechanism as the scala.concurrent.SyncVar[T] class.

This Scala REPL session demonstrates how it works:

 scala> import concurrent._ import concurrent._ scala> import ops._ import ops._ 

I import ops._ to create another Thread .

 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 creating another thread. get blocked until there is a value in syncInt .

 scala> syncInt.isSet res1: Boolean = false scala> syncInt.set(103) scala> got 103 

The above was printed by the stream we created earlier.

 scala> syncInt.isSet res3: Boolean = true scala> syncInt.get res4: Int = 103 
+11
source

It looks somewhat like a synchronous queue with one element, where the user must wait for the manufacturer to offer a value.

+5
source

It looks like an Exchanger to me, if you don't consider it more one-sided ... did you look at it? Basically, you don’t have to worry about what you have provided on the expectation side, or what you have received from the “provision” part.

I agree with you that it looks like the future, except for the "executable" part.

+4
source

I created a very similar thing called BlockingReference , where I needed consumers (one or many) to be able to read the last value or block until it became available. In essence, this is similar to a single-element queue, since the producer thread can publish a new value at any time, and then continue. This is relevant when the only information that needs to be published is some kind of status update. I use it, noting the progress in multi-threaded cache for distributing content (where one stream loads content and there are several consumers relaying the downloaded bytes). The main difference from yours is that yours is one-time.

This implementation is significantly superior to SynchronousQueue and Exchanger , since both of them block the flow of the manufacturer until a handover occurs. It surpasses the performance of Scala SyncVar as the producer thread is implemented without any locks or features, as it can support multiple consumers. It has been optimized with high performance.

Atlassian Concurrency lib is licensed by Apache2 and is hosted in our public Maven repository.

+1
source

This is somewhat related to streaming programming .

0
source

Source: https://habr.com/ru/post/1339607/


All Articles