Re: New New Callbacks Uploaded

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 
any
> >> template parameter requirements exist. And if they are not 
satisfied
> >> that is the problem of the client code rather than the supplied 
> >code.
> [...]
> >I believe the argument was being made to internalize thread 
> >synchronization in the callback.  I stated that you don't always 
have 
> >a requirement that callbacks be thread safe (they can be used in 
> >single threaded programs, or can be insured to never be passed 
across 
> >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 
the
> point of the view that the object must be thread safe whereas you 
are
> 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. 
In
> other words, the requirement would be that operator(), or any other 
op,
> would be thread safe, for some appropriate implementation of thread
> safety for the functional object. Sorry for the confusion, I should 
have
> 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 
all 
> >of those)
> 
> Ternary and quaternary :-) I suggested nullary, unary and binary 
because
> they are the only we have support/concepts for in Boost and the
> standard.

I doubt this will remain in the future, so to restrict yourself here 
is a mistake. 

Bill Kempf