Re: [boost] Re: New New Callbacks Uploaded

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-11-29 12:38:22

In message <9036bj+107ri_at_[hidden]>, William Kempf <sirwillard_at_my-
deja.com> writes
>--- 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.  

Of course it can! It's a non-functional requirement, just as many of the
generic requirements are.

>A lot of function objects must carry 
>state around with them, state which is modified with each invocation 
>of operator().  

Some, but certainly not the major part. Function objects fall into three
categories wrt state:

(1) Stateless, eg functions, many of the function object types in the
standard, many predicates, many transformations.

(2) Stateful but with fixed state, eg many bound function objects, many
of the other function object types in the library, many predicates, many
transformations.

(3) Stateful but with changeable state, eg RNGs, accumulators.

In my experience, category (1) and (2) cover most of the uses, eg the
callback examples cited, predicates, etc would fall into these
categories, hence no need for synchronisation. Category (3) is the
minority category, IME, and it is only category (3) that definitely
requires synchronisation.

>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.

Lock-free and no-synchronisation are both options. I'm not sure what you
are not seeing!

However, to counter that, I raised this option only to suggest that it
was too restrictive. If you look at one of my original emails, I
rejected this option and COW because they were unworkable or awkward for
one reason or another, which left proper copying as the appropriate
solution. I suspect this discussion exists for reasons of
misinterpretation!

>> >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. 

I am not restricting myself, I am restricted by the library. Given that
the components in the library are open to change (by us), I do not
consider this to be much of an issue: establishing semantics and
interface principles is so far ahead of it that it vanishes in the rear
view mirror :->

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Limited               mobile: [phone]
  mailto:kevlin_at_[hidden]     fax:    [phone]
  http://www.curbralan.com
____________________________________________________________