what's the point of rpython?
rhamph at gmail.com
Thu Jan 22 08:14:00 CET 2009
On Jan 21, 9:46 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> Rhamphoryncus <rha... at 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.
More information about the Python-list