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-
> >> 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
> 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
> think that. However, it does show (unless you wish to quibble with
> definition of show ;->) that the responsibility for thread
> synchronisation is not the responsibility either of the function
> we are discussing or of the function object or function that the
> 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
> >The callback can't insure any sort of thread
> >> >safety for the copy process when a deep copy is performed,
> >> >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 --
> >> 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
> >in order for the copying of the function object to be thread
> >These state objects are not a part of the function object library,
> >but are data types created by the programmer outside of the
> >Thus the library can not gaurantee that copy of these state
> >is thread safe. Thus the library can not gaurantee that copying
> >function object is thread safe.
> If I understand you correctly, are you saying that on execution of
> ctor there are potentially two threads running through the object?
> 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
> program. If what you said was true, we would not be able to program
> strings, ints, etc. However, what you say is not true. Programming
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk