From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-30 15:54:19
--- In boost_at_[hidden], Kevlin Henney <kevlin_at_c...> wrote:
> In message <903oa0+7kdd_at_e...>, William Kempf <sirwillard_at_my-
> deja.com> writes
> >> >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.
>
> I am talking across applications. I can hand on heart say that I
would
> be surprised if you believed that the main use for function objects
was
> to carry modifiable state. They are a use, but I think relatively
few
> people believe they are the main use.
Sorry, but "main part" and "a major part" are quite different
concepts (you did say "the major part" which could be equivalent
to "main part" but that argument is pointless so I assumed you
meant "a major part"). I don't care if 75% of the usage fits your
other categories, if 25% fits the third category it MUST be addressed
accordingly in the implementation. And frankly, I think we've made a
case that for many of us it's at least close to this, if not
exceeding it. For STL algorithm usage I might reduce this to your
point of view, but, frankly, the concept being discussed here is
needed precisely because we're using it in places and for uses other
than STL algorithms. Closures are going to be a very big usage for
this concept, and closures are nearly always modified state function
objects.
> >> 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).
>
> This was addressed in the other email. What is meant here is pure
> functions. Sorry, I should have been more explicit.
>
> >> (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.
>
> Sorry, I didn't realise that my emails were so open to
misinterpretation
> so frequently! From what I can tell, I think much of our discussion
has
> come from this :-}
Well, I'll take at least some blame here. When I read posts in
discussions like this I often have problems seeing other points of
view unless they are explicitly stated as different view points.
Instead I see them as criticisms of the view that I hold (which isn't
bad, it just means I misinterpret things when the track is changed
like this).
> Let me summarise: (1) and (2) cover most cases, (3) is significant
but a
> minority. This means that although one could make a case for
requiring
> immutability based on majority rule, it would be too restrictive
because
> it would foreclose, unreasonably, the possible use of (3). This is
what
> I meant in an earlier posting as being too restrictive, and hence
why I
> felt it an unreasonable design.
And now I'm lost. Too many messages in between these posts,
probably. The possible use of (3) causes what to be an unreasonable
design how? It _seems_ like you're agreeing with what I've been
trying to get across here with this paragraph, but then I'm not sure
why we've argued back and forth for a while ;).
> >> >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.
>
> I'm still not sure what you are not seeing. Are you confusing the
idea
> of an option with a rule? One is optional and the other is not. For
> instance, lock-free and no-synchronisation are options for (1), (2)
and
> (3) depending on their specifics. For the majority of cases in (3),
> however, it ceases to become an option because explicit
synchronisation
> is definitely required. I am not sure I can put it any more clearly
than
> that! :-}
I'm not sure that there are any specifics for (3) that would allow
for lock-free and no-synchronization, other than cases where thread
boundaries aren't crossed. In any event, since (3) can't be dealt
with any where but within the implementation of the function object,
you've got the problems I've alluded to. A callback library can not
address threading issues here as long as cloning is used with out
cooperation from the wrapped function object, which is intrusive and
I'm not sure is an option here.
Bill Kempf