[cpp-threads] Slightly revised memory model proposal (D2300)

[Nick Maclaren]

"Alexander Terekhov" <alexander.terekhov at gmail.com> wrote:
> 
> > > > or SIGFPE) and SIGSEGV etc.
> > >
> > > These are synchronous (not asynchronous) signals which C++
> > > implementations are free to translate to C++ exceptions. Don't get me
> > > started on std::unexpected() and C++ EH/ES, contact Dimov and/or
> > > Abrahams.
> >
> > Yes and no.
> 
> http://h71000.www7.hp.com/doc/73final/6493/6101pro_030.html
> 
> For the signals traditionally representing synchronous errors in the
> program, the Threads Library catches the signal and converts it into
> an equivalent exception. This exception is then propagated up the call
> stack in the current thread and can be caught and handled using the
> normal exception catching mechanisms. ...

Sigh.  Been there - done that.

I have implemented it for several languages, and was involved in
IBM's CEL (which did the same for 3 platforms and 5 languages).
The fact of the matter is that it can be anywhere from simple to
impossible, depending on details of the hardware, operating system
and compiler.

Are you familiar with architectures like the Alpha, where floating-
point exceptions are not normally synchronous?  Vector and pseudo-
vector systems, which often make the Alpha look a synchronous
design?  Ones without virtual memory (or with virtual address caches),
where exceptions due to a failed store may not be synchronous?

I have implemented turning store failures into exceptions on a
machine where the equivalent of SIGSEGV was not synchronous.  It can
be done, but it is isn't as easy as it might appear.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679