Threads (WAS: setjmp/longjmp implementations)

chase@Think.COM (David Chase) writes:
>[Stack switching is only a few lines of assembly, which is why I
> get ticked off when people try to use `longjmp'.]


On the SPARC, stack switching is only a few lines of assembly (though the
faster version is a few more lines than shown in <94-02-104>). On some
other machines, though, it's more and it's trickier. More important,
though, I think it's reasonable for programmers to avoid even *one* line
of assembly code if there's a portable implementation. That, I think, is
why people try to use `setjmp' and `longjmp' to implement threads. It
doesn't work, of course, but the goal is to avoid machine dependencies.


Digression: Among other things, it's hard (e.g., computationally more
expensive) to make `longjmp' work for stack switches because (a) some
programs rely on on the "old" semantics (local variables are preserved
whether or not they're declared `volatile') and (b) because machines
without stacks link together heap-allocated activation records; `longjmp'
would have to determine whether the control transfer is between stacks or
within a single stack. When it's within a single stack, some number of
activation records must be freed during the `longjmp'. This is clearly
possible to do, but it's more work than just bindly freeing them during
the `longjmp' stack walk.


I have written a threads library package with a portable (C) interface and
the machine description for saving and restoring registers for context
switching ranges from a few lines (VAX, SPARC) to hundreds of lines
(KSR1). The code is available via anonymous ftp from
`ftp.cs.washington.edu' (128.95.1.4) in `pub/qt-001.tar.Z' (be sure to do
the transfer in binary mode). It includes code for AXP, ix86, KSR1,
m88000 MIPS R3000 and VAX targets, and all except the KSR1 support both
varargs and more efficient single-arg functions. The tech report is on
the same machine in `tr/1993/05/UW-CSE-93-05-06.PS.Z'.


;-D on ( Following this thread of discussion ) Pardo
--

Return to the comp.compilers page.
Search the comp.compilers archives again.