Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <h2><code>scala.actors._</code></h2> <h3><code>abstract class Future</code></h3> <p>First of all, lets see what the documentation says:</p> <blockquote> <p>A function of arity 0, returing a value of type T that, when applied, blocks the current actor (Actor.self) until the future's value is available.</p> </blockquote> <p>And that is basically all there is. If you are communicating with an Actor from anywhere outside of another actor (which can receive asynchronous replies to messages simply with another message, using the <code>sender</code> reference) and you need the reply to a sent message, you have two choices:</p> <ul> <li>Send a blocking message which waits until the Actor is done computing your result</li> <li>Send a message using a method which returns a Future, and block on that Future only if you really need the value in question (which by then may have alreay been computed)</li> </ul> <p>So a Future is a placeholer for a value which does not yet exist, but probably will in the <em>near future</em>. The following is also interesting:</p> <blockquote> <p>A future can be queried to find out whether its value is already available without blocking [using "isSet"].</p> </blockquote> <p>This allows you to do whatever you want until the value you need has been computed/fetched, and you can periodically check if the value has become available.</p> <p>When digging a bit into the Scala library source code, I found out that Futures are actually just actors. <code>Future</code> itself is a an <code>abstract class</code>, which is extended by the <code>private class FutureActor</code>. This last class is the one that actually implements the <code>Future</code>-functionality.</p> <h3><code>object Futures</code></h3> <p>The <code>object Futures</code> is by far not as interesting, as it is merely a container for the <em>"Methods that operate on futures"</em>, the handy factory method <code>future</code> which asynchronously evaluates the passed block, returning a future representing the result. A small example would be this:</p> <pre><code>import scala.actors.Futures val f = Futures.future { println("Start: inside block") val s = System.currentTimeMillis while(System.currentTimeMillis &lt; (s + 1000)) { // Simulate computation } println("Start: end of block") 42 } println("After future") println(f()) println("The end") </code></pre> <p>Which should result in something like</p> <pre><code>Start: inside block After future Start: end of block 42 The end </code></pre> <p>This demonstrates that the <code>future</code>-call does not block the following code until you actually try to retrieve the value of the future (note that the output is <a href="http://en.wikipedia.org/wiki/Nondeterministic_algorithm" rel="noreferrer">non-deterministic</a>. <code>After future</code> could also appear at the beginning of the output).</p> <h2><code>scala.collection.parallel</code></h2> <p>This packages is new to Scala 2.9.x and implements parallel counterparts for some of our favorite collections. These all start with <code>Par</code>:</p> <ul> <li>ParIterable</li> <li>ParSeq</li> <li>ParSet</li> <li>ParMap</li> </ul> <p>As you may have known or guessed already, these collections implement all possible operations in a parallel manner without you having to worry about it. A small demonstration:</p> <pre><code>(1 to 10).par.map { b =&gt; print(b + " "); b * b } 3 1 6 2 7 4 5 9 10 8 # =&gt; (1, 4, 9, 16, 25, 36, 49, 64, 81, 100) </code></pre> <p>The result will always be the same, but the order in which the elements are processed is again non-deterministic. Also, if you are on a multicore system, you will probably experience a nice performance boost for larger collections.</p> <h3><code>trait FutureThreadPoolTasks</code></h3> <p>The <code>FutureThreadPoolTasks</code> trait extends the <code>Tasks</code> trait, so lets take a look at that one first. The comment above the trait says:</p> <blockquote> <p>A trait that declares task execution capabilities used by parallel collections.</p> </blockquote> <p>Judging from the other source comments and the methods found in the <code>Tasks</code> trait, a Task represents a unit of work which needs to be computed. Depending on wether or not a problem is divisible further and if there are more resources available, a Task can split up a Task further by creating more tasks.</p> <p>Now the <code>FutureThreadPoolTasks</code> trait itself is just a way to compute tasks, which uses the <code>java.util.concurrent.Future</code> class for its synchronization, that is, it <strong>does not</strong> use <code>scala.actors.Future</code>! From the source:</p> <blockquote> <p>An implementation of tasks objects based on the Java thread pooling API and synchronization using futures.</p> </blockquote> <h3><code>object FutureThreadPoolTasks</code></h3> <p>Once again not very spectacular, just a companion object containing a few (actually only three) utility methods which the <code>FutureThreadPoolTasks</code> trait uses.</p> <h2><code>scala.concurrent</code></h2> <p>The documentation on these classes is really bad and apparently there are very few if any (I didn't find a single one) examples which demonstrate the usage of these classes. I will definitely try to gather more information on these and expand on this section as soon as I can!</p> <h2><code>scala.parallel</code></h2> <h3><code>trait Future</code></h3> <p>This seems to be a "Work in progess", as the <code>scala.parallel</code> package only contains this trait. From what I can tell, this is going to be related to a <code>Future</code> implementation which does not use <code>Actors</code>, but that is just a guess. The signature of the trait is the following</p> <pre><code>trait Future[@specialized +R] extends (() =&gt; R) </code></pre> <p>I am not even going to try to explain <a href="http://lamp.epfl.ch/~dragos/files/scala-spec.pdf" rel="noreferrer">the @specialized annotation</a> or <a href="http://www.scala-lang.org/node/129" rel="noreferrer">variances </a> (the + before the generic R type), but the basic idea in this trait is that a Future is a function which, when executed, returns the value (and must therefor block if it has not been computed yet).</p> <p>Also, there are only two methods inside the trait itself, <code>apply</code> and <code>isDone</code>. My guess is that <code>isDone</code>, just like the <code>scala.actors.Future.isSet</code>, is supposed to be a non-blocking call to see if the value has been computed, and the <code>apply</code> method should be used to actually retrieve the value.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload