Re: [sigc] Re: [gtkmm] libsigcx and gtkmm 2.4

[Martin Schulze <martin-ml hippogriff de>]

Am 13.06.2004 19:45:57 schrieb(en) Daniel Elstner:
> Am So, den 13.06.2004 um 18:30 Uhr +0200 schrieb Martin Schulze:
> > >
> > > > knows of it. Note that sigc::bind does not take arguments as
> > > references
> > > > by default if this is where you are heading.
> > >
> > > std::string can be implemented with reference counting, and the
> > > libstdc++ shipped with GCC does exactly that.
> >
> > Meaning that no deep copy of the string is made although it is
> passed
> > "by value"?! Then I understand the problem here.
>
> Exactly.
>
> > (However, if you pass a "const char*" into the std::string ctor as
> in
> > my example the copy is being created at once, isn't it?)
>
> Right.  But you have to lock *before* creating the std::string  
> object!
>
> > I still don't see the problem in the case where no
> references/pointers
> > are being passed around: The list of slots the dispatcher operates
> on
> > _is_ protected by memory barriers (there might be bugs in my code
> but
> > it is perfectly possible to simply use a mutex around 'std::list::
> > push_back()' / 'std::list::pop_front()' as I pointed out in a
> comment
> > and as Christer does).
>
> Sure, but the caller passes in an already constructed std::string.   
> As
> I
> said above, you need to lock before constructing the object.

Sorry, I'm a bit lame at the moment. I'm trying to express the problem  
in a simple flow table with a *bang* at time=t+4:


time    thread A should do (*does)               thread B [*does]
-------------------------------------------------------------------
t       construct slot
                   (*slot is partly constructed)
t+2     acquire lock
                   (*lock is acquired)
t+3     add slot to list
t+3     release lock
                   (*slot is added to list)
                   (*lock is released)
t+4     idle                                      [*accesses slot]
t+5                 (*construction of slot is finished)


Is this a possible scenario? I can't think properly about it at the  
moment - too tired. Note that slot is copied again while adding to the  
list during std::list::push_back(). I would assume that this copy is  
fully initialized before the lock is actually released. Of course in  
the case of our std::string this is still a problem because the newly  
constructed string is a shallow copy of the old one. But for static  
data types everything should be all right, shouldn't it?

Regards,

 Martin