From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-29 10:11:47
--- In boost_at_[hidden], Kevlin Henney <kevlin_at_c...> wrote:
> In message <8vttdv+tjq9_at_e...>, William Kempf <sirwillard_at_my-
> deja.com> writes
> >> >> Exactly. It would be part and parcel of the function object
> >> >> requirements.
> >> >
> >> >Except that the requirements don't always exist.
> >> I'm not sure what you mean by this: They would exist inasmuch as
> >> template parameter requirements exist. And if they are not
> >> that is the problem of the client code rather than the supplied
> >I believe the argument was being made to internalize thread
> >synchronization in the callback. I stated that you don't always
> >a requirement that callbacks be thread safe (they can be used in
> >single threaded programs, or can be insured to never be passed
> >thread boundaries). Simply internalizing thread synchronization
> >would be prohibitive in these cases, since it will add significant
> >overhead in memory and speed.
> Aha, I see we are coming from different perspectives: I was taking
> point of the view that the object must be thread safe whereas you
> viewing thread safety as equivalent to synchronisation.
> Whilst synchronisation is one way of ensuring thread safety in the
> presence of change, my point was that lock-free synchronisation (eg
> atomic operations) and immutable objects satisfied the requirement.
> other words, the requirement would be that operator(), or any other
> would be thread safe, for some appropriate implementation of thread
> safety for the functional object. Sorry for the confusion, I should
> been more explicit.
I did not think you were coming from this angle because frankly, it
can't be done generically. A lot of function objects must carry
state around with them, state which is modified with each invocation
of operator(). First, such modifications can rarely be made thread
safe with out synchronization. Second, these modifications occur
outside of the realm of any function object library.
I'm not even sure you can leave that portion up to the programmer and
insure the rest within the function object library. After all, you
have to address the copying of the function objects, which may have
to "atomically" copy state.
No, lock-free synchronization doesn't appear to be an option here,
unless you've got some technique in mind that I've not seen.
> >I just see major restrictions that shouldn't exist. Why only
> >nullary, unary and binary? Where's trinary? Quadnary? (sp? on
> >of those)
> Ternary and quaternary :-) I suggested nullary, unary and binary
> they are the only we have support/concepts for in Boost and the
I doubt this will remain in the future, so to restrict yourself here
is a mistake.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk