Talk:Atomic updates: Difference between revisions
Content added Content deleted
(Is it about mutexes?) |
(reply) |
||
| Line 1: | Line 1: | ||
Please clarify the task. Transfer of a bucket value cannot be defined atomic operation while preserving the object's invariant. The solutions presented are incorrect in this sense because they do not have transfer '''safe'''. They rather provide an '''unsafe''' transfer with locking the object externally (to the transfer). Because transfer does not keep the object's invariant it is not an operation of. So what was the purpose of the task? Just to show a use of mutex? Then the task looks superfluous, since there is already [[mutex]] task. --[[User:Dmitry-kazakov|Dmitry-kazakov]] 12:44, 17 May 2009 (UTC) |
Please clarify the task. Transfer of a bucket value cannot be defined atomic operation while preserving the object's invariant. The solutions presented are incorrect in this sense because they do not have transfer '''safe'''. They rather provide an '''unsafe''' transfer with locking the object externally (to the transfer). Because transfer does not keep the object's invariant it is not an operation of. So what was the purpose of the task? Just to show a use of mutex? Then the task looks superfluous, since there is already [[mutex]] task. --[[User:Dmitry-kazakov|Dmitry-kazakov]] 12:44, 17 May 2009 (UTC) |
||
: I'm sorry, but I don't understand the distinctions you're making. How is the transfer operation unsafe? If you're just concerned about the nonnegative requirement, I've revised the task to include what my E implementation actually does. The difference between this task and [[mutex]] is that this task does not explicitly require the use of a mutex; my E example does not use a mutex, and it could also be implemented using, for example, [[wp:software transactional memory]]. The purpose of this task is to demonstrate a basic task in concurrency: ensuring that a data structure preserves its invariants in the presence of concurrent access. --[[User:Kevin Reid|Kevin Reid]] 15:17, 17 May 2009 (UTC) |
|||
Revision as of 15:17, 17 May 2009
Please clarify the task. Transfer of a bucket value cannot be defined atomic operation while preserving the object's invariant. The solutions presented are incorrect in this sense because they do not have transfer safe. They rather provide an unsafe transfer with locking the object externally (to the transfer). Because transfer does not keep the object's invariant it is not an operation of. So what was the purpose of the task? Just to show a use of mutex? Then the task looks superfluous, since there is already mutex task. --Dmitry-kazakov 12:44, 17 May 2009 (UTC)
- I'm sorry, but I don't understand the distinctions you're making. How is the transfer operation unsafe? If you're just concerned about the nonnegative requirement, I've revised the task to include what my E implementation actually does. The difference between this task and mutex is that this task does not explicitly require the use of a mutex; my E example does not use a mutex, and it could also be implemented using, for example, wp:software transactional memory. The purpose of this task is to demonstrate a basic task in concurrency: ensuring that a data structure preserves its invariants in the presence of concurrent access. --Kevin Reid 15:17, 17 May 2009 (UTC)