Re: New New Callbacks Uploaded

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-12-04 10:03:19

--- In boost_at_[hidden], Kevlin Henney <kevlin_at_c...> wrote:
> In message <90918a+gred_at_e...>, William Kempf <sirwillard_at_my-
> deja.com> writes
> >> There truly is. Some of the commonest such bindings, eg event-
based
> >> callbacks, use pointers rather than objects by value.
> >
> >This makes little difference.  So the modification of the state is 
> >indirect instead of direct for some cases, this doesn't eliminate 
the 
> >problem.
> 
> Yes, this makes the world of difference. It means that the function
> object is not, as you claim, changing its own state. Of course, this
> does not eliminate synchronisation issues, and it would be foolish 
to
> think that. However, it does show (unless you wish to quibble with 
the
> definition of show ;->) that the responsibility for thread
> synchronisation is not the responsibility either of the function 
wrapper
> we are discussing or of the function object or function that the 
user
> provides. Can we agree on that?

You've just gotten very close to the argument I've been presenting 
ever since you decided to use thread safety as a criteria for 
choosing cloning.

> >The callback can't insure any sort of thread 
> >> >safety for the copy process when a deep copy is performed, 
while 
> >it 
> >> >can be insured for shallow ref-counted copies.
> >> 
> >> I believe you have this back to front. Perhaps you would like to
> >> demonstrate what you are thinking with a code fragment -- 
English 
> >does
> >> not seem to be serving us well ;->
> 
> <sigh> This is not code :-(

Because we're talking about thread safety here, giving code to 
illustrate the point would be much more complex than the description 
of the problem given.  You could not simply look at the code and see 
the problem, since the problems may only crop up occasionally by the 
very nature of threading issues.
 
> >A deep copy requires copying of all state that may be contained 
> >within a function object.  This copying of state must be thread 
safe 
> >in order for the copying of the function object to be thread 
safe.  
> >These state objects are not a part of the function object library, 
> >but are data types created by the programmer outside of the 
library.  
> >Thus the library can not gaurantee that copy of these state 
objects 
> >is thread safe.  Thus the library can not gaurantee that copying 
the 
> >function object is thread safe.
> 
> If I understand you correctly, are you saying that on execution of 
the
> ctor there are potentially two threads running through the object? 
Only
> if you've got a bug in your program! Copying rather than sharing of
> objects is well recognised as a safe way to pass information around 
a
> program. If what you said was true, we would not be able to program 
with
> strings, ints, etc. However, what you say is not true. Programming 
with
> threads and objects contains a number of pitfalls, and I believe you
> have fallen into one of them :-(

Sorry, what I'm saying *is* true.  Think about a string that's shared 
across threads.  Imagine that one thread is attempting to concatenate 
another string to it while another is attempting to copy it.  With 
out synchronization between these threads you've got exactly what you 
said couldn't be true.

This problem is one of the problems that's lead to the need for 
synchronization concepts.  Yes, in some cases it's possible to design 
the program to insure that this particular problem never occurs, but 
that's what thread safe programming is all about.  You can't assume 
that everything was written this way, insuring you thread safety 
every where.  When you say that "copying rather than sharing of 
objects is well recognized as a safe way to pass information around" 
you've made to mistakes:  this is true only when the copy is 
gauranteed to be thread safe and in our case you've not insured that 
sharing isn't still occuring despite the copy.

No, neither form can insure thread safety unless the wrapped objects 
are insured to be thread safe, which is up to the programmer, not the 
library.  However, ref-counting allows the library to minimize the 
potential for thread synchronization bugs by reducing copies to one 
well defined location and then synchronizing around operator() calls 
to insure thread safety for cases where the wrapped object doesn't 
share data with any external sources.  This makes the programmers job 
slightly easier when it comes to thread safety issues, though it 
doesn't eliminate the issues.

So, discussing thread safety as a reason to choose one over the other 
is a red herring, but if you insist going down that path it leads to 
ref-counting not cloning.

Bill Kempf