what's the point of rpython?

Brendan Miller catphive at catphive.net
Tue Jan 20 21:13:15 CET 2009

On Tue, Jan 20, 2009 at 3:46 AM, Paul Rubin
<"http://phr.cx"@nospam.invalid> wrote:
> skip at pobox.com writes:
>> Carl, I'm quite unfamiliar with Boost and am not a C++ person, so may have
>> read what you saw but not recognized it in the C++ punctuation soup.  I
>> couldn't find what you referred to.  Can you provide a URL?
> http://www.boost.org/doc/libs/1_37_0/libs/smart_ptr/shared_ptr.htm#ThreadSafety

I think you are misreading that. It says that multiple assignments to
different copies of a share_ptr in different threads are fine. This is
the important bit because copies of the same pointer share the same
reference count, and assignments and resets will decrement that ref
count. They say they don't handle mutations of the *same* pointer in
different threads, which is a different issue.

The programmer is responsible for synchronizing access to the pointer,
and the pointed to object, but not the ref count. This may be not be
obvious if you don't use shared_ptr a lot.

You also mentioned in an earlier post that most processors don't
support automic increments... I'm hesitant to dispute you here because
this is outside of my field of expertise. However, a quick google
search for "x86 atomic increment" comes up with this:



Again, I'm not an assembly guru, but his sounds like exactly what
you'd want. It gains exclusive access to system memory in a
multi-processor environtment without leaving user space. Thus XADD is
an atomic increment/decrement. It would be educational if someone more
famliar with x86 than me could speak to the performance merits of this
on modern multicore machines.

More information about the Python-list mailing list