Boost logo

Boost :

Subject: Re: [boost] Synchronization (RE: [compute] review)
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2014-12-31 04:47:13

On December 30, 2014 5:58:10 AM EST, "Gruenke,Matt" <mgruenke_at_[hidden]> wrote:
> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Rob
> Stewart
> > BOOST_NO_EXCEPTIONS invokes a global handler to note a failure. That
> means
> > after every library call, the user must check a global value to
> determine
> > if there was an error. Overloading with a Boost.System error_code
> localizes
> > error checking. (Asio does this, for example.) I consider that a
> superior
> > way to avoid exception overhead.
> Either way, I don't see how you avoid checking whether an error
> occurred after each operation.

You don't, but one is local to the last function call and the other is a global value.

> And when you do detect an error, then
> you can certainly skip some work, but you're still stuck waiting for
> the non-failed operations to complete before you can destroy any of
> the datastructures they're using. And that would be much simpler with
> a good contingent of RAII-friendly constructs, like those we're
> discussing.


> Therefore, I don't see the issue of exceptions vs. error codes (nor
> the mechanism of error code access) being relevant to the discussion
> of synchronization.

People were looking for ways to avoid exceptions. Whether that was to support embedded environments without exception support or to avoid exception overhead, I don't know.

> The synchronization support needs to be there, no
> matter what. And it should be relatively unobtrusive and easy to use.


> > The question is whether exception overhead is a bottleneck in coding
> with this
> > library's API. It is necessary to weigh the likelihood of errors
> against the
> > costs of reporting and detecting them. Conditional logic to check
> for errors
> > is not pipelining friendly, but throwing exceptions is terribly
> expensive.
> By comparison with network programming (since you cited Boost.ASIO),
> GPU/OpenCL errors should be far less common. Therefore, error
> handling needn't be optimized for performance.

What about embedded programming environments without exception support?

> BTW, the types of operations generating these errors typically involve
> communication with a device or at least a couple syscalls. So, the
> kind of ALU pipeline effects of conditional statements that you
> mention aren't relevant, here.

They still apply if the error checking is done on the host side.


(Sent from my portable computation engine)

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