Race in boost::shared_ptr?
Dmitriy Vyukov
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
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();
> }
> }
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
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();
> > }
> > }
>
>
> 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
Chris M. Thomasson
news:6cb0a92f-56e4-4f35...@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.
Rani Sharoni
> Is it only me who thinks that there is a race?
> 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?
Not in the context of ref counted objects.
To acquire reference from the object there is need to some sort of
synchronization that guarantees the memory visability.
For example:
lock()
sp = m_sp; // take reference to member
unlock();
return sp;
Rani
Dmitriy Vyukov
I'm not sure I get your point. That's not about acquire, that's about
release. And a thread can release a reference w/o any additional
synchronization.
--
Dmitriy V'jukov
Rani Sharoni
> On 3 янв, 11:53, Rani Sharoni <ranisharon...@gmail.com> wrote:
>
>
>
> > On Dec 27 2009, 2:25 pm, Dmitriy Vyukov <dvyu...@gmail.com> wrote:
>
> > > Is it only me who thinks that there is a race?
> > > $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?
>
> > Not in the context of ref counted objects.
> > To acquire reference from the object there is need to some sort of
> > For example:
>
> > lock()
> > sp = m_sp; // take reference to member
> > unlock();
>
> > return sp;
>
> I'm not sure I get your point. That's not about acquire, that's about
> release. And a thread can release a reference w/o any additional
> synchronization.
How did the thread got a reference to the object in the first place?
Can you show a use case in which there is memory visibility issue on
release?
Thanks,
Rani
Chris M. Thomasson
news:49d7450b-3c3b-453c...@o28g2000yqh.googlegroups.com...[...]
> > I'm not sure I get your point. That's not about acquire, that's about
> > release. And a thread can release a reference w/o any additional
> > synchronization.
> How did the thread got a reference to the object in the first place?
> Can you show a use case in which there is memory visibility issue on
> release?
http://groups.google.com/group/comp.programming.threads/browse_frm/thread/192923ee5fb14d9f
Rani Sharoni
> "Rani Sharoni" <ranisharon...@gmail.com> wrote in message
Sorry. a bit too long for me to get a use-case per my above questions.
Thanks,
Rani