comp.programming.threads - 5 new messages in 2 topics - digest

comp.programming.threads
http://groups.google.com/group/comp.programming.threads?hl=en

comp.programming.threads@googlegroups.com

Today's topics:

* a lock-based proxy collector? - 1 messages, 1 author
http://groups.google.com/group/comp.programming.threads/t/3b70d0ead8e62e15?hl=en
* Race in boost::shared_ptr? - 4 messages, 2 authors
http://groups.google.com/group/comp.programming.threads/t/9cce4454db522705?hl=en

==============================================================================
TOPIC: a lock-based proxy collector?
http://groups.google.com/group/comp.programming.threads/t/3b70d0ead8e62e15?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Dec 26 2009 3:50 am
From: Dmitriy Vyukov

On Dec 25, 4:50 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:

> The key elements are objects are deferred in FIFO order. After two mutations
> occur, one can pop a node off the FIFO and destroy it because it's
> quiescent. I believe there are many improvements I can make to this
> lock-based collector as well as non-blocking collectors based on the same
> basic logic. I will do further testing with Relacy...
>
> What do you think about this Dmitriy?

I need to think on this.
Currently I am busy with my new CopyOnWrite-MultiVersion-ReaderWriter-
Transactional-Sequence-Lock. Doing tests and benchmarks on 2 processor/
8 core/16 hw threads Xeon and 8 core/64 hw threads UltraSPARC T2. It's
fun to see how traditional mutexes (pthread_mutex_t/pthread_spinlock_t/
pthread_rwlock_t) behave in synthetic benchmarks on such machines :)

--
Dmitriy V'jukov

==============================================================================
TOPIC: Race in boost::shared_ptr?
http://groups.google.com/group/comp.programming.threads/t/9cce4454db522705?hl=en
==============================================================================

== 1 of 4 ==
Date: Sun, Dec 27 2009 4:25 am
From: Dmitriy Vyukov

Is it only me who thinks that there is a race?
Here is a piece of code from boost_1_41_0\boost\smart_ptr\detail
\sp_counted_base_solaris.hpp, it implements simple reference counting
with basic-thread safety:

void release() // nothrow
{
if( atomic_dec_32_nv( &use_count_ ) == 0 )
{
dispose();
weak_release();
}
}

$man atomic_ops
NOTES
Atomic instructions ensure global visibility of atomically-
modified variables on completion. *In a relaxed store order
system, this does not guarantee that the visibility of other
variables will be synchronized with the completion of the
atomic instruction. If such synchronization is required,
memory barrier instructions must be used*. See
membar_ops(3C).

I think there must something along the lines of:

void release() // nothrow
{
*membar_exit()*;
if( atomic_dec_32_nv( &use_count_ ) == 0 )
{
*membar_enter()*;
dispose();
weak_release();
}
}

Agree?

--
Dmitriy V'jukov

== 2 of 4 ==
Date: Sun, Dec 27 2009 4:47 am
From: Dmitriy Vyukov

On Dec 27, 3:25 pm, Dmitriy Vyukov <dvyu...@gmail.com> wrote:
> Is it only me who thinks that there is a race?
> Here is a piece of code from boost_1_41_0\boost\smart_ptr\detail
> \sp_counted_base_solaris.hpp, it implements simple reference counting
> with basic-thread safety:
>
>     void release() // nothrow
>     {
>         if( atomic_dec_32_nv( &use_count_ ) == 0 )
>         {
>             dispose();
>             weak_release();
>         }
>     }

You may see the full source here:
https://svn.boost.org/trac/boost/browser/trunk/boost/smart_ptr/detail/sp_counted_base_solaris.hpp

Maybe Solaris does just not run SPARC in RMO... then comment in man
atomic_ops is quite misleading, though.

--
Dmitriy V'jukov

== 3 of 4 ==
Date: Sun, Dec 27 2009 4:59 am
From: Dmitriy Vyukov

On Dec 27, 3:47 pm, Dmitriy Vyukov <dvyu...@gmail.com> wrote:
> On Dec 27, 3:25 pm, Dmitriy Vyukov <dvyu...@gmail.com> wrote:
>
> > Is it only me who thinks that there is a race?
> > Here is a piece of code from boost_1_41_0\boost\smart_ptr\detail
> > \sp_counted_base_solaris.hpp, it implements simple reference counting
> > with basic-thread safety:
>
> >     void release() // nothrow
> >     {
> >         if( atomic_dec_32_nv( &use_count_ ) == 0 )
> >         {
> >             dispose();
> >             weak_release();
> >         }
> >     }
>
> You may see the full source here:https://svn.boost.org/trac/boost/browser/trunk/boost/smart_ptr/detail...
>
> Maybe Solaris does just not run SPARC in RMO... then comment in man
> atomic_ops is quite misleading, though.

Indeed. Paul McKenney in his fundamental "Memory Ordering in Modern
Microprocessors" states that "Solaris on SPARC uses total-store order
(TSO)":
http://www.linuxjournal.com/article/8212

What then NOTE in man atomic_ops does mean? Is it just 'back route'
for the case if Sun will ever switch to PSO/RMO?

--
Dmitriy V'jukov

== 4 of 4 ==
Date: Sun, Dec 27 2009 1:55 pm
From: "Chris M. Thomasson"

"Dmitriy Vyukov" <dvyukov@gmail.com> wrote in message
news:6cb0a92f-56e4-4f35-b252-7f67ada4b80a@v25g2000yqk.googlegroups.com...
On Dec 27, 3:47 pm, Dmitriy Vyukov <dvyu...@gmail.com> wrote:
> > On Dec 27, 3:25 pm, Dmitriy Vyukov <dvyu...@gmail.com> wrote:
> >
> > > Is it only me who thinks that there is a race?
> > > Here is a piece of code from boost_1_41_0\boost\smart_ptr\detail
> > > \sp_counted_base_solaris.hpp, it implements simple reference counting
> > > with basic-thread safety:
[...]
> >
> > You may see the full source
> > here:https://svn.boost.org/trac/boost/browser/trunk/boost/smart_ptr/detail...
> >
> > Maybe Solaris does just not run SPARC in RMO... then comment in man
> > atomic_ops is quite misleading, though.

> Indeed. Paul McKenney in his fundamental "Memory Ordering in Modern
> Microprocessors" states that "Solaris on SPARC uses total-store order
> (TSO)":
> http://www.linuxjournal.com/article/8212

> What then NOTE in man atomic_ops does mean? Is it just 'back route'
> for the case if Sun will ever switch to PSO/RMO?

I would guess that you are right.

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.programming.threads"
group.

To post to this group, visit http://groups.google.com/group/comp.programming.threads?hl=en

To unsubscribe from this group, send email to comp.programming.threads+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.programming.threads/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en