[Caml-list] POSIX Threads: kill

[Caml-list] POSIX Threads: kill

[Christoph Bauer]

Hi All,


in file ocam-3.06/otherlibs/systhreads/thread_posix is this comment:

(* Thread.kill is currently not implemented due to problems with
   cleanup handlers on several platforms *)

Is anybody working on it? Is there a solution for linux-i386?

Thanks,
Christoph Bauer

-- 
proc self {} {foreach c [split [info body self] ""] d {14 -7 0 0 4 -67 4 73 11
69 24 -83 -15 6 -4 -84 78 20 11 -78 -1 -1 79 19 -8 4} { binary scan $c c c
if {[catch {append r [format %c [expr $c+$d]]}]} {return $r};}};puts [self]

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] POSIX Threads: kill

[Xavier Leroy]

> in file ocam-3.06/otherlibs/systhreads/thread_posix is this comment:
> 
> (* Thread.kill is currently not implemented due to problems with
>    cleanup handlers on several platforms *)
> 
> Is anybody working on it?

The problem is as follows.  

POSIX threads have a notion of cleanup handlers, which are functions
that are called when the thread dies, either voluntarily (via
pthread_exit) or by being cancelled by another thread (via
pthread_cancel).

On some platforms (Tru64 Unix for sure, perhaps Solaris as well),
cleanup handlers are implemented via C++ exceptions.  (It is true that
POSIX threads is a C interface, however the Tru64 C compiler
understands C++ exceptions even when compiling pure C sources.)
Namely, a cleanup handler is mapped to a try... finally construct that
just does the right thing.

The problem is that C++ exception handling is based on unwinding stack
frames one by one till a matching exception handler is found.  This
requires stack frames to adhere strictly to a particular format, and
be equipped with stack descriptors that the C++ stack unwind mechanism
understands.  But of course the stack frames used ocamlopt-generated
code do not adhere to this format, and do not come with C++ stack
descriptors.  Hence, if the "systhreads" library was using
pthread_exit and pthread_cancel, the C/C++ runtime system would try to
unwind Caml stack frames, and just crash the whole program.

> Is there a solution for linux-i386?

LinuxThreads on Linux doesn't rely on C++ exceptions, so it doesn't
suffer from the problem above.  However, LinuxThreads is being
replaced by NPTL, another, better threading library for Linux, and I
don't know how NPTL implements cleanup handlers.

The general solution is to avoid using Thread.kill.  Terminating another
thread at arbitrary times is an inherently unsafe operation: the
killed thread may be holding mutexes, for instance.  There's a good
explanation of the problems in the Java documentation:

http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html

explaining why they "deprecated" their equivalent of Thread.kill.

- Xavier Leroy

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] POSIX Threads: kill

[John Carr]

> The problem is that C++ exception handling is based on unwinding stack
> frames one by one till a matching exception handler is found.  This
> requires stack frames to adhere strictly to a particular format, and
> be equipped with stack descriptors that the C++ stack unwind mechanism
> understands.  But of course the stack frames used ocamlopt-generated
> code do not adhere to this format, and do not come with C++ stack
> descriptors.  Hence, if the "systhreads" library was using
> pthread_exit and pthread_cancel, the C/C++ runtime system would try to
> unwind Caml stack frames, and just crash the whole program.


If I recall correctly, on some systems this is an easy problem to
solve because there is little or no runtime overhead in using the
standard stack layout and stack descriptor overhead.

On the other hand, ocaml does not use register windows on SPARC and
fixing that would be a big change.  Did somebody determine that the
"flat" model was faster, or was it just easier to implement?  SPARC
v9 may change the equation because it was designed to make save and
restore instructions fast, reducing window overflow traps to under
50 cycles.


(I remember trying to mix C++, exceptions, and threads back in 1995.
The combination was so unreliable that I gave up.  If a program used
exceptions the exception handlers interfered with thread stack
unwinding and caused core dumps inside the Solaris C++ support library.)

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] register windows

[Xavier Leroy]

> On the other hand, ocaml does not use register windows on SPARC and
> fixing that would be a big change.  Did somebody determine that the
> "flat" model was faster, or was it just easier to implement?

I experimented both approaches (with and without register windows) on
the SPARC a long time ago, in the Gallium experimental compiler
(which, after a complete rewrite, became the OCaml native-code compiler).
IIRC, there was one test where register windows were slightly faster;
on most tests, they were somewhat slower; and on a few tests involving
deep recursion, the code using register windows was 10-50 times slower
than the code that didn't use them.  I believe the Chez Scheme people
conducted similar experiments, with the same conclusions.

> SPARC v9 may change the equation because it was designed to make
> save and restore instructions fast, reducing window overflow traps
> to under 50 cycles.

A fixed-size register window is always going to save and restore too
many registers.  Even with variable-sized windows like on the IA64,
I believe it's more efficient to schedule explicit spills and reloads in
between regular instructions than rely on the hardware and OS to move
window contents to and from the stack.

- Xavier Leroy

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] register windows

[John Carr]

> A fixed-size register window is always going to save and restore too
> many registers.

As long as you stay within the eight windows implemented in hardware
saving the extra registers costs nothing -- a save instruction takes
one cycle.

Register windows were invented when somebody observed that programs
tended to stay within a small range of call depth.  That observation
is about 25 years old.  Since then inlining has reduced call depth
while the rise of giant libraries with layers and layers of wrapper
functions has increased call depth.

The question is, are present-day ocaml programs typically the sort for
which register windows are better?

> IIRC, there was one test where register windows were slightly faster;
> on most tests, they were somewhat slower; and on a few tests involving
> deep recursion, the code using register windows was 10-50 times slower
> than the code that didn't use them.

UltraSPARC should improve the speed ratio of the last class by a
factor of a few compared to older SPARC and may also help windowed
programs with shallow call depths.

I plan to try changing to code generator to use windows and do some
tests, but I won't get around to that any time soon.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] register windows

[Xavier Leroy]

> > A fixed-size register window is always going to save and restore too
> > many registers.
> 
> As long as you stay within the eight windows implemented in hardware
> saving the extra registers costs nothing -- a save instruction takes
> one cycle.

Well, you're thinking of the best case, and I'm thinking of the worst
case where the 8 hardware windows will overflow -- and in many
programs involving recursion, they do overflow very often.  In this case, the
whole contents of one or several windows are stored in memory (or
reloaded from memory), including those registers that are not used by
the program.  So, even if the corresponding OS traps have no overhead
(which is not true), the processor ends up doing more memory stores
and loads than strictly necessary.

> Register windows were invented when somebody observed that programs
> tended to stay within a small range of call depth.  That observation
> is about 25 years old.  Since then inlining has reduced call depth
> while the rise of giant libraries with layers and layers of wrapper
> functions has increased call depth.
> 
> The question is, are present-day ocaml programs typically the sort for
> which register windows are better?

My guess is "no".  Heavy use of recursion, as encouraged by Caml,
leads to call depths much larger than what the SPARC designers
observed on a few C programs 25 years ago.

- Xavier Leroy

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] POSIX Threads: kill

[John Max Skaller]

John Carr wrote:

 
> (I remember trying to mix C++, exceptions, and threads back in 1995.
> The combination was so unreliable that I gave up.  If a program used
> exceptions the exception handlers interfered with thread stack
> unwinding and caused core dumps inside the Solaris C++ support library.)


FYI the C++ committee is currently addressing this issue.


-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners