Boost logo

Boost :

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-
>> writes
> >--- In boost_at_[hidden], Kevlin Henney <kevlin_at_c...> wrote:
> >> In message <8vttdv+tjq9_at_e...>, William Kempf <sirwillard_at_my-
> >>> 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
> >any
> >> >> template parameter requirements exist. And if they are not
> >satisfied
> >> >> that is the problem of the client code rather than the
> >> >code.
> >> [...]
> >> >I believe the argument was being made to internalize thread
> >> >synchronization in the callback. I stated that you don't
> >have
> >> >a requirement that callbacks be thread safe (they can be used
> >> >single threaded programs, or can be insured to never be passed
> >across
> >> >thread boundaries). Simply internalizing thread
> >> >would be prohibitive in these cases, since it will add
> >> >overhead in memory and speed.
> >>
> >> Aha, I see we are coming from different perspectives: I was
> >the
> >> point of the view that the object must be thread safe whereas
> >are
> >> viewing thread safety as equivalent to synchronisation.
> >>
> >> Whilst synchronisation is one way of ensuring thread safety in
> >> presence of change, my point was that lock-free synchronisation
> >> atomic operations) and immutable objects satisfied the
> >In
> >> other words, the requirement would be that operator(), or any
> >op,
> >> would be thread safe, for some appropriate implementation of
> >> safety for the functional object. Sorry for the confusion, I
> >have
> >> been more explicit.
> >
> >I did not think you were coming from this angle because frankly,
> >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
> >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
> 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,
> of the other function object types in the library, many predicates,
> transformations.
> (3) Stateful but with changeable state, eg RNGs, accumulators.
> In my experience, category (1) and (2) cover most of the uses, eg
> 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
> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at