Basic support for ref

[austinzheng]

I don't think I can implement a proper STM system. However, a decent approximation that might serve for low-traffic purposes follows:

A ref is represented by a reference type (type with identity) encapsulating:

• A mutable value type cell
• A GCD queue (I think refs can share queues, not sure about this though)
• A counter

A read-only transaction is simple: the value type is simply copied and returned to the owner. Since value types in Swift are COW, mutations to the value type shouldn't touch the mutable cell. I believe that COW is thread-safe (as opposed to, e.g. mutating a var containing a collection across multiple threads).

A dosync transaction is modeled roughly in the following way: a transaction closure is run on the local queue, which takes in the counter and a copy of the cell value. When finished, a nested closure is dispatched to the ref's queue with the new value and the counter.

If the counter has not changed, the ref increments the counter and updates the value, and dispatches a completion closure to the local queue.

If the counter has changed, the ref dispatches the transaction closure to the local thread again, but with an updated copy of the cell value and an updated counter value. The transaction is then re-run, as described previously.

This basically corresponds to a lock to start the transaction and a lock to end it (ensuring that transactions are processed in a well-defined order). However, the concurrency mechanism is work queues, not locks or mutexes.

The main technical challenge is naming the queues to dispatch between. It's possible that a namespace (or whatever mechanism is used to model a thread of execution) can hold on to the name of its queue, allowing it to be retrieved from GCD by the ref data structure.