Re: Exploiting Dual Core's with Py_NewInterpreter's separated GIL ?

Ross Ridge wrote:
Ross Ridge schrieb:

So give an example where reference counting is unsafe.


Martin v. Löwis wrote:

Nobody claimed that, in that thread. Instead, the claim was
"Atomic increment and decrement instructions are not by themselves
sufficient to make reference counting safe."


[...]

The problem your describing isn't that reference counting hasn't been
made safe. What you and Joe seem to be trying to say is that atomic
increment and decrement instructions alone don't make accessing shared
structure members safe.

How you increment and decrement a reference count is an implementation
issue and whether it's correct or not depends on the semantics of the
refcount based pointer. I.e. what kind of thread safety guarantees
are we ascribing to pointer operations? Java reference (pointer)
guarantees are not the same as C++ Boost shared_ptr guarantees. In
Java simple pointer assignment, "a = b;" is always safe no matter what
any other thread may be doing to a and/or b. With shared_ptr you have
to have a priori knowlege that the refcount for b will never go to
zero during the copy operation. Usually that implies ownership of b.

To get a better feeling for the latter semantics you should take a look
at C++ String implementations. A C++ String COW (copy on write) implementation
using atomic inc/dec is as thread-safe as a non-COW String implementation
because in both cases you have to own the strings you access.

About the term "thread-safe". In Posix it's taken as meaning an operation
on non-shared data isn't affected by other threads. So non-COW strings
are thread-safe, and COW strings are thread-safe if their internal
refcounting is synchronized properly. But note that in both cases,
the implemention is transparent to the user.

So as you say, a lot depends on how you access or want to access shared
structure members, e.g. with or without locking.


--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software. .

Relevant Pages

  • Re: Concurrency and delegates
    ... It's thread safe in that it won't throw a NullReferenceException. ... there's some behind-the-scenes locking going on? ... the memory models I've seen. ... in fact the close to the recommended practice for thread-safe ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Concurrency and delegates
    ... Is that because there's some behind-the-scenes locking going on? ... Or is it because the event can be copied in a single CPU-atomic operation? ... it's safe - but it's not *strictly speaking* safe under ECMA. ... in fact the close to the recommended practice for thread-safe ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Exploiting Dual Cores with Py_NewInterpreters separated GIL ?
    ... The race condition you describe is different from the one Joe Seigh ... It's caused because without GIL access to the file object ... not because reference counting isn't thread ... automatically thread-safe". ...
    (comp.lang.python)
  • Re: setting timer
    ... >> here copied below for your convenience. ... This definition of safe has a particular meaning, ... then it is safe". ...
    (comp.unix.programmer)
  • Re: Thread-safe assignments
    ... I realize that my recent question about thread-safe caches was pretty ... Is it safe to assume that the reading threads will only ever read the ... More precisely, instructions themselves tend to be atomic, ...
    (comp.lang.lisp)