"Consistancy" -- see last para but one and second point in the first ordered list.

Even when I could not see how the RFC allowed for modifications (which it doesn't), I allowed for the existance of such a mechanism, but concluded that the overhead would likely be too high for inter-thread shared variable access. Once you explained the mechanism you envisaged, I reached the same conclusion. Seems consistant to me?

I do truely believe in the ideas that I spout, and I do my very best to research my ideas to some conclusion. That doesn't mean I'm always (or ever) right--that would imply inhuman, infallability. The whole (and only) purpose for my interacting in this way is to find out if I am wrong; so that I may learn.

There are certain subjects upon which I actively avoid interaction--religion, editors, OSs to name a few--because I have arrived at an opinion that has been tested to the point that I see no purpose in discussing it further. These are fairly few and far between, and exclusively subjective, rather than objective matters. On most everything else I am open to debate.

Yes. I read the other node. I still see the same problem though. In order to allow for modification x = f(x); in the distributed database, the first thread that needs to read the value for modification has to:

1. Request ownership; (not described in RFC 677)

   For this step to operate, once this request makes it to the top of the request queue:

   1. the request *must* be forwarded to every other database that has a copy of the variable being owned.
   2. The receiving DBM's will not process this request until the requests come to the top of their request queues.
   3. A positive confirmation of that request must be awaited from each duplicate holder.

   In a networked environment, the outbound requests can be deserialised through broadcasting. The inbound confirmations can arrive in any order. (Both help minimise the delays). In a threaded environment, the recieving threads will not process their inbound queues until they get a timeslice, the sending queue will not be able to receive the confirmations until it gets a time slice. Timeslicing is non-determanistic and unordered. Even if every other thread had an empty inbound queue, it could take several timeslices per sharing thread before a single request/confirmation cycle was complete. The ownership requesting thread would need to block for this entire time.

   And what happens if another thread has dispatched a request for ownership prior to receiving the request from this thread?

   Can't happen you say, because all requests are time-ordered (sequence numbered), therefore, no outbound request can be sent until an earlier inbound request has been fully processed.

   The upshot of that, is that all processing on all threads of all shared (distributed) values must be performed in lock-step.

2. Request the current value; (Selection)
3. Calculate f(x);
4. Request update of the value; (Assignment)

   The distributed notification/confirmation cycle repeats here.

5. Relinguish ownership; (not in RFC 677)

   And again here.

Effectively, the timebase (sequence numbers) becomes the cpu clock for all operations in the system that involve shared values.

To put that in perspective, you would reduce your 2(3 or 4) Ghz cpu to having a clock frequency of a few 10s or hundreds of cycles per second, for any operation that involved shared variables.

In a networked application like DNS, where changes are often deemed to take days to propogate and if it happens within a couple of hours it's a pleasent surprise, this low-frequency clock cycle is not a problem--but for a cpu-intensive code applications it would be fatal.

When I mentioned "slow as molassses", I was not exagerating.