Add support for M-structures (MVars) about concurrent-ruby HOT 7 CLOSED

Scala's SyncVar has a different semantic than yours, it is more like to a "single element queue", where a put on a set component just blocks the thread.
Maybe we can try to add a non-blocking try_put(value) method that returns true if the value has been set and false otherwise or a timeout to a blocking put

I don't like the name, it sounds too much "academic" and it is not well suited for everyday use, but I also think is a good building block: Ruby standard library is very poor in concurrency and those facilities are very useful.

from concurrent-ruby.

You're right about the semantics of SyncVar and put, and that's what MVar is - my example was wrong. The Scala semantics are what I intend to implement.

I'll go ahead and implement this as well. I'll call it SyncVar for now.

from concurrent-ruby.

I'm not familiar with Scala's SyncVar but I like the idea expressed by MVar. If Scala's SyncVar implements the desired behavior then I like the idea of basing our implementation on Scala. It fits withe the theme of this library.

from concurrent-ruby.

SynchVar seems a little too cryptic to me...
I mean: we're describing a container that can hold only one object, blocking when we try to put into another one object or if we try to get something that is not available yet.
What about Slot?

from concurrent-ruby.

I just read the documentation for Scala's SyncVar and the description therein is "A class to provide safe concurrent access to a mutable cell."

Is "Cell" a reasonable name for this class, or is that too obscure? I'm fine with SyncVar, too. It's obscure but since that's the name Scala uses there is precedent.

from concurrent-ruby.

I prefer "Cell" over "SyncVar" because it conveys the idea: we have one cell that could be empty or full with blocking operations.

from concurrent-ruby.

Starting implementation in #17.

from concurrent-ruby.