Re: [boost] Re: Re: Re: Platform Neutrality-withoutreinterpret_cast<>andifdef

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-08-07 10:17:21

----- Original Message -----
From: "Victor A. Wagner, Jr." <vawjr_at_[hidden]>
> At Tuesday 2002/08/06 07:36, you wrote:
> >From: "Victor A. Wagner, Jr." <vawjr_at_[hidden]>
> >To: <boost_at_[hidden]>
> > > Geez, I hate to have to chime in on Eric's side (since I disagree with
> >some
> > > of what he says), but it _should_ be the "stated" or "posted" will of
the
> > > community.  I found the arguments ("they're not safe") for deleting
> > > semaphore so specious that I gave up on attempting any further
criticism.
> >
> >You shouldn't have.  Semaphores weren't relegated to absolute
non-inclusion.
> >They were removed as being dangerous enough to warrant serious research
and
> >design before consideration of actual inclusion.
>
> we disagree here.  I worked for almost 20 years building embedded systems
> on which people's lives depended with "raw semaphore" as the underlying
> synchronization method.  As I commented the last time this came up, we had
> the advantage of not being hindered by a "language" which in it's design
> gave NO thought to multi-tasking, rather we were designing both the
> instructions sets and the computers on which the systems would run.

I won't beat a dead horse.  It's not only my opinion that semaphores are
dangerous... it's the opinion of several experts in the field.  But the
point you missed is that semaphores aren't simply gone from Boost.Threads.
They are simply in a list of things that need careful consideration before
including.  I don't know if they'll be in Boost.Threads in the end or not...
though I do know in which direction I'm leaning.

> >  A polling form of exception passing is
> >usable for select cases.
>
> is IS unusable for select cases, and "simply marvelous" for others.

We'll have to agree to disagree.

> > > I'm suggesting that we quit using "it might not be safe if misused" as
a
> > > mantra.  It's a consideration, that's all.  "Gee, this might be unsafe
if
> >I
> > > misuse it...I'd better be careful."
> >
> >Sorry, I honestly don't feel I've done this.
>
> semaphores are NOT in boost:threads (as near as I can tell, because of
> this).

But you miss several points:

* Semaphores may not be gone for good.  They were removed solely so that the
appropriate research good be made to determine their suitability for
inclusion.

* There's nothing the Semaphore gives you that isn't present in
Boost.Threads.  Most of what you use a semaphore for is handled by a
mutex... and the rest is covered through conditions.  The only possible
thing the semaphore can buy you is performance... and there's several people
who should know who claim there isn't a performance benefit either.

> > > We're not children here.  We handle dangerous things every day
(knives,
> > > driving, etc).
> > > The language cannot protect against a lot of things that will cause
the
> > > program to blow up, why are we so worried about this one?
> >
> >Because from experience this particular area of computing is one that
> >produces the largest amount of bugs, and the bugs are extremely difficult
to
> >detect during testing, and to diagnose and correct once detected (usually
in
> >production).
>
> fortunately, code walkthru/review by _many_ peers kept us out of that
> problem for the main part.  I _do_ remember the one trip into the field to
> chase a problem of this nature (which turned out to be some code _I'd_
> written) which was found as I was in the middle of a presentation on why
> the problem couldn't be "my fault" when I realized that, in fact, it was.

Then you should be acutely aware of the problem, even if you don't quite
grasp the importance here.  You were on a team that had a lot of expertise
in this area and were working on critical systems that resulted in extremely
thorough reviews.  Most users today don't fall into this camp (even if you
could argue that they should).  More over, if the system can eliminate many
possible misuses how much time could have been saved in those reviews you
talk of?  The cost alone here should be compelling.  Further, there are
plenty of people who would rather not rely on a system that required that
amount of human review to determine correctness.

> >   The need to consider safety is a little higher here then in
> >other areas, even though you're still left with plenty of rope to shoot
> >yourself in the foot with.
>
> I don't want to shoot myself in the foot.  I want a FAST simple
> inter(process/thread) synchronization system.

And you don't think you have that with Boost.Threads?  Care to point out
areas where it fails here?

> suppose we now move the implementation of myfunc to another machine
> (RPC?  SOAP??)
> Should what the user sees have to change?  Can we throw an exception from
> myfunc?

Apples and oranges.  You're at a much higher level.  The function the user
calls is synchronous, regardless of whether or not the implementation relies
on asynchronous calls behind the scene.  This isn't the case with thread
creation, where the calling thread need not block awaiting the result, or
even use the result.  This means the exception can be simply lost, which is
something that should never occur with an exception.  By calling terminate
you insure the exception can never be lost.  More importantly, this practice
in no way prohibits the user from properly handling the exceptions thrown,
which in your example would mean having the calling thread throw an
exception.

>  No, yes respectively.  Of course, this requires that we come up
> with some changes to the 'standard communications interface' and figure
out
> how to "pass an exception back".  When we do that (which requires
> developing a protocol for the exceptions) it becomes easy.  The "wrapper"
> on the target machine does a
> try{do_the_real_work;}catch{}catch{}catch{}catch(...){} send the proper
> "reply".

Your example uses not only MT concepts, but interprocess communication and
even call remoting.  That's something that's very FAR outside of the scope
of a MT library such as Boost.Threads.  It's going to require very specific
exception handling to make it work, and is actually an argument in my favor
because of this.  It's trivial to implement for your specific use case,
showing that the Boost.Threads design in no way prohibits you from doing
this, where as the proposed change in no way helps this use case and
provides a very large possibility for lost exceptions.

> Now writing the wrapper/encoder/decoder/exception-builder is a non-trivial
> task (it's not a research project, but it's not an hour hack either)

For your use case I don't agree.  COM reports all exceptions through an
HRESULT, which is translated to a C++ exception on the client side through a
class that anyone could implement in much less than an hour.  Do you get a
mechanism in which the server component can throw any exception and
magically the client side gets the exact same type?  Nope... but I'm not
convinced that's appropriate any way.  Across the wire like this you pretty
much have to have rigid exception specifications.

> Suppose the writer of myfunc() discovers a way to improve its performance
> by starting a couple helper threads.  If the current design includes
> exceptions, s/he is going to have to re-invent some form of the 'wrapper'
> to pass the exceptions from the child threads back to the parent and a
> wrapper to reconstruct the exception.  Naturally, the exception cannot be
> thrown until some sort of "join" function is called. Not an insurmountable
> job, but why have everyone who needs this invent their own.

I'm not suggesting they should have to.  I would suggest however, that the
thread is not the appropriate wrapper for this.  This kind of thing belongs
in the function object, and would be useful in many cases other than this
thread case.  For instance, it could be used in the Boost.Signals library
where the calls are conceptually asynchronous if not physically
asynchronous.  And then there's your use case of RPCs, where a completely
different implementation will be required because you have to wire the
exception.

And again, I have to point out that all of this is assuming a synchronous
call wrapper.  With out that, the idea is dangerous at best.

Bill Kempf