Comments on: Creating a reorderable task list – Managing gadget states with concurrency in mind

By: A Wave Gadget + Robot using GWT 2.0 and Google App Engine, Part 1 « The Zukunft

Tue, 09 Feb 2010 02:14:55 +0000

[...] that the only atomic state operations wave supports are the change of a single key. Inspired by Avital Oliver’s great blog post, I came up with the following scheme for saving gadget [...]

By: Google Wave Gadgets using MooTools

Google Wave Gadgets using MooTools — Mon, 07 Sep 2009 16:44:18 +0000

[...] the source code for task list gadget and the original blog post about [...]

By: KonstantinMiller

KonstantinMiller — Mon, 06 Jul 2009 22:20:20 +0000

I have been looking looking around for this kind of information. Will you post some more in future? I’ll be grateful if you will.

By: Avital Oliver

Avital Oliver — Mon, 22 Jun 2009 21:17:47 +0000

Very interesting comments, Omri. Thanks for the references to the “official” names of things.

The reorderable task list gadget has sequential consistency and I hope that the framework will allow for all gadgets to have that property. But there may be other operations (e.g. switching the position of two items) and perhaps some of these operations can’t be implemented using this scheme with sequential consistency.

If that is the case we will have to figure out a different model for the framework. But I don’t believe in thinking too much before doing. Once we start building the framework and the gadgets we will discover these issues and figure them out.

By: Omri

Omri — Mon, 22 Jun 2009 20:23:48 +0000

I am not deeply familiar with Google Wave but from reading your post i take it they allow for a shared state between gadgets. This shared state can basically be looked at as shared memory in a multi processor architecture, for example. What you are basically trying to solve, is the same issue that happens in these kind of shared memory architectures.

Values can be used indefinitely as long as no one decides to change them, but as soon as one participant changes something, the other participants need to either be aware their local value is no longer relevant, or know what to expect when they attempt to concurrently modify the same value. This is usually referred to as “Memory coherence”.

There are various methodologies developed over the years to support different consistency models.
A consistency model means which type of consistency will always be kept in the shared memory.
For example, if I have two transactions occurring in parallel:

t1 = [key1 = v1, key2 = v2]
t2 = [key1 = v3, key2 = v4]

A sequential consistency model would guarantee that the state of the shared memory would be as if we picked an order between t1 and t2 and performed them in a sequential (uni-processor) order, t1 and then t2, or vice versa. From Wikipedia (http://en.wikipedia.org/wiki/Sequential_consistency):
“…It was first defined as the property that requires that “… the result of any execution is the same as if the operations of all the processors were executed in some sequential order, and the operations of each individual processor appear in this sequence in the order specified by its program…”

In any case, these transactions will never intertwine which would result in an inconsistent state of [key1 = v1, key2=V4], which would never happen

In your post you talk about specific state manipulation to solve this problem in your specific realm of internal state (like new position being an average of old positions). If I were to look at this as a framework for developers, the question I would draft and try to solve:

Given a shared memory representation of key value pairs, an atomic modification scheme which changes a set of key values in a synchronized fashion, which types of memory coherence protocols/algorithms can I implement and which consistency model can I support?