what's the point of rpython?

[Rhamphoryncus]

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.