Re: New New Callbacks Uploaded

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-29 15:18:08

--- In boost_at_[hidden], Kevlin Henney <kevlin_at_c...> wrote:
> In message <9036bj+107ri_at_e...>, 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.

I don't follow you here.  Pardon my denseness, but sometimes it seems 
like english is a second language to me ;).

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

That's debatable, and frankly depends on the application.

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

Functions aren't necessarily stateless.  A static or global variable 
can be used to maintain state (though difficult to use in MT apps).
 
> (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 matter what you experience, (3) is a large enough category to need 
addressing.  For some applications it's a very large category, maybe 
even the only category.  You can't dismiss it as a corner case just 
because of your experience.

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

As long as (3) above exists you've got problems here.
 
> 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!

You're still dismissing, out of hand, ref-counting.  I realise that 
this changes the semantics, but you've not given a reason to prefer 
one set of semantics over another.

BTW, if you read the other posts and look at the solutions provided 
thus far, no one was considering COW here.  The discussion between 
ref-counting vs. cloning was just that, not COW vs. cloning.

Bill Kempf