On Jan 21, 9:46 pm, Paul Rubin <http://phr...@nospam.invalid> wrote: > Rhamphoryncus <rha...@gmail.com> writes: > > a) The contended case is the issue, not the uncontended case. An > > uncontended lock is just constant overhead, not a barrier to > > scalability > > a1) Really what matters is the actual mix between contended and > uncontended accesses, and the synchronization strategy affects the > amount of contention. For example, the traditional locking strategy > involves acquiring a lock before reading the object, so two > simultaneous read-only accesses would create lock contention. With > STM, only updates acquire a lock, so multiple read-only threads can > access the object simultaneously with no contention.
Aye, but my point is really about the myth of lock-free algorithms being uncontending — it's simply not true, and CAN'T be true. A write is inherently a mutually exclusive operation. There's all sorts of ways to avoid contending for reads, spread out the writes and have a single thread coalesce them, etc, but fundamentally the write will involve some mutual exclusion. -- http://mail.python.org/mailman/listinfo/python-list