Empty / Full Storage

Axum has a couple of storage modifiers not found in most other languages (although several languages incorporate futures and / or promises, similar concepts).

Axum has three modifiers that are useful mostly with concurrent algorithms, for synchronization between agents within a domain or between interleave branches within an agent. For inter-domain synchronization, channels remain the only method.

Here’s an example:

 async int x; 
const string str; 
sync object obj;

These storage modifiers can be used for locals, parameters, domain and agent fields, etc. (but not as schema properties).

Such variable all have in common that they can be empty or full at any given point in time. Being empty is different from a nullable type having the value null, it literally means that the variable does not hold a value of any kind and therefore cannot be read. Readers will block when trying to get the value out of an empty location (of course, the compiler does the right thing to make it scalable).

As a category, we call this “empty full storage.” Readers of an empty storage location always block and writers can always write to an empty location. What is more interesting is what happens when the variable is full. We have the following possibilities:

Writers may…

• … block until the location is empty.
• … throw an exception.
• … overwrite the value already stored at the location.

Readers may…

• … get a copy of the data and leave the location full.
• … empty the location after reading it.

One can imagine having support for these operations on a single storage component, but we have chosen to define different components for three out of the six combinations that are possible.

They are:

• async, where writers overwrite and readers copy
• sync, where writers block and readers empty
• const, where writers throw and readers copy

Async is roughly the normal variable storage semantics, except that it can be empty if not initialized; sync is roughly a synchronous producer / consumer buffer, and const is a single-assignment variable. One neat thing is that ‘const’ is a generalization of a C# const variable; with the exception of the possibility to deadlock, it behaves just like a const in that each read operation that completes will return the same data.

If you return a const from a method, you are essentially giving the caller a handle to a future value. Const variables are not as flexible as full-fledged promises, though.

All three are useful for communicating between agents, while async and const are also useful when used in dataflow networks, as they are sources and targets. You can imagine a network which processes an incoming message and places the result in a const variable, which is then read by some control-flow-based code that blocks until the value is available.

When used in networks, both async and const act as broadcasters; the only difference is that const variables will only broadcast one single message to its targets.

Three Questions

Empty / full storage is one of the more controversial aspects of Axum among the members of the internal team. There are those who think syntactic support in the language is useful and necessary, and there are those who would prefer to just see runtime classes implement these concepts. Which is right? I suspect it’s hard to answer that until you try it out for real, but it’s worth thinking about a bit.

Also, are the three above the right set? Artur Laksberg posted something on throttling earlier; his first example, where messages are dropped by the consumer could be reduced to a one-line modification of the consumer agent code if we had something where writers overwrite and readers empty. Are there other things we’re missing? throw/empty seems like a recipe for introducing races in code, and block/copy seems, well, silly…

Third, there are those on the team who would argue that ‘async’ is a bad moniker for its particular semantics (overwrite/copy). I would disagree, but there is another language feature that we all agree it would be better for, so we want to find another keyword for the storage modifier, and I’m therefore asking for your help with that. It has to be short (4-5 characters) and a good mnemonic for the semantics of the storage. Any and all suggestions will be considered…

Niklas Gustafsson

Axumite

Comments

• Anonymous
  May 02, 2009
  PingBack from http://microsoft-sharepoint.simplynetdev.com/empty-full-storage/

• Anonymous
  May 02, 2009
  How about "var" instead of async? not sure if that's already a keyword. If it is, then how about "varies". Going in a different direction, what about "slot". You can get the value of a slot by looking at it. New values you put in kick stuff out of the slot. Going along the same lines, what about: "pixel", "display", Or what about just "loc" (from 'location')? the analogy is with a regular memory location.

• Anonymous
  May 02, 2009
  I see the overwrite/copy model as more "soft" or "fluid" and the block/empty model as more "hard", "solid" or "concrete".  Something like:    solid object task;    fluid int temperature;

• Anonymous
  May 03, 2009
  A few weeks ago, the 2009 Lang.NET symposium was came and went and there were a few talks that caught

• Anonymous
  May 03, 2009
  A few weeks ago, the 2009 Lang.NET symposium was came and went and there were a few talks that caught

• Anonymous
  May 12, 2009
  What about 'volatile' instead of async?

• Anonymous
  May 16, 2009
  async => shared ? async => norm ? i like "volatile" above but could be shortened to "vol" My concern is also that if you change "async" then changing "sync" might be appropriate

• Anonymous
  May 20, 2009
  The comment has been removed

• Anonymous
  May 23, 2009
  It’s been two weeks since we released the CTP on DevLabs . Thousands of people have downloaded it, tried

• Anonymous
  October 14, 2010
  I think if interaction points were extensible and you provided building blocks we would build  different kinds of storages and  wrap them in reusable classes.