Talk:Atomic updates: Difference between revisions

:::I don't understand how it is unsafe. The transfer increases one bucket by the same amount it decreases another bucket, so it preserves the invariant. The Ada solution is incorrect because the data structure does not have a ''general'' transfer operation that could be used in other ways, just two special cases. (Of course, in the end this task is arbitrary -- feel free to argue that I should change the definition.) --[[User:Kevin Reid|Kevin Reid]] 16:52, 18 May 2009 (UTC)

::::Hmm, what is "general transfer" that preserves the invariant? To me transfer is to move something from one place to another. This is possible to do atomically, but impossible while keeping certain invariants. Ada solution implements atomic update as suggests the task name. Transfer there is only a part of update. Maybe you mean a user-defined procedure atomically applied to a pair of buckets? I.e. the operation takes two buckets and a user procedure that updates them while the object is locked. This is a possible scenario, but again, it does not preserve the invariant. So, IMO, one of the things must be dropped: 1. invariant, 2. transfer as an update, 3. specific updates, which aren't just transfers. I dropped 2 (transfer), because this the most common case it concurrent programming. You have some object with low-level operations like transfer, which are inherently unsafe (non-atomic, kill the invariant etc). You hide them in the implementation and provide higher level operations, which are safe, but of course, not so flexible as the low-level ones. (I asked about mutexes, because initially I thought you wanted to illustrate transactions: one initiates a transaction (locks the object), does some unsafe things, like transfers, and then closes the transaction (fixes the invariant and unlocks the object). Of course there could be lock-free solutions, but that is besides the point.) --[[User:Dmitry-kazakov|Dmitry-kazakov]] 18:02, 18 May 2009 (UTC)