Warning: Unstable POSIX threads support comitted to CVS

Warning: Unstable POSIX threads support comitted to CVS

[Mikael Djurfeldt]

[-- Attachment #1: Type: text/plain, Size: 2551 bytes --]

Hi,

Based on Marius copt threads work, I've now put together an initial
version of full POSIX threads support with preemptive thread
scheduling.  This is especially good to have if you, like me, use
multi-cpu machines.

Attached to this letter is an example program:

  par-fib N DEPTH --> fibonacci number N

The number is computed by forking to DEPTH levels.
For example, (par-fib 100 4) creates 31 threads (with 16 threads at
the base level, reverting to iterative computation of the rest).
(par-fib 100 5) crashes for me... :)

Well, yes, the current state of the code is slightly broken.  Just as
before this change, the null-threads alternative won't build, and the
threading alternative is the default.  The idea is that we for the
coming couple of weeks can make a collaborative effort of finding bugs
and fundamental problems.

However, single-thread use seems stable (although there could be some
problems with errors in macro transformers).

We need to work on signal delivery and exceptions.  One suggestion is
that we continue to *only* deliver signals at SCM_ASYNC_TICK points.
The effect of signal delivery (normally a throw) is then pretty well
controlled.  A novel (?) suggestion is this:

It is very irritating that signals are delivered to whatever thread
happens to run for the moment.  Is it possible to add explicit
interactive control over which thread is the "foreground" thread?
Only the "foreground" thread gets signal delivery (=> that thread gets
its async lists marked regardless of which thread reacted on the
signal).  Normally, the "foreground" is the repl loop thread, and we
can have a small "command language" (perhaps ordinary scheme
procedures) to inspect status of the other threads and explicitly
deliver signals like "SIGINT".

One further area which needs work is the current recursive critical
sections (SCM_REDEFER/REALLOW_INTS, SOURCE_SECTION in eval.c etc).
They need to be optimized (use real POSIX recursive mutecis if
available).  We should also add a mechanism for resetting (unlocking)
the associated mutecis on an error throw.  This can be made by adding
a line for registering the critical section in
SCM_REC_CRITICAL_SECTION in snarf.h.

I and Marius hope to fix the most basic problems within a few days.
Then I think we'll have an acceptable level of stability.  And, as
Marius have said before, the thread suppport is in a state of flux.
Much can still change...

(BTW, there seems to be some unrelated build problem right now due to
the recent change to versioning.)

Best regards,
Mikael D.


[-- Attachment #2: Thread test program --]
[-- Type: text/plain, Size: 370 bytes --]

(define (par-fib n n-forks)
  (cond ((<= n 1) 1)
	((> n-forks 0)
	 (letpar ((f1 (par-fib (- n 1) (- n-forks 1)))
		  (f2 (par-fib (- n 2) (- n-forks 1))))
	   (+ f1 f2)))
	(else
	 (let ((f1 (mono-fib (- n 1)))
	       (f2 (mono-fib (- n 2))))
	   (+ f1 f2)))))

(define (mono-fib n)
  (let iter ((f1 1) (f2 1) (i 1))
    (if (>= i n)
	f2
	(iter f2 (+ f1 f2) (+ 1 i)))))

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Warning: Unstable POSIX threads support comitted to CVS

[Marius Vollmer]

Mikael Djurfeldt <djurfeldt@nada.kth.se> writes:

> It is very irritating that signals are delivered to whatever thread
> happens to run for the moment.

Do you refer to the execution of POSIX signal handlers or to the
execution of Scheme signal handlers?  Scheme handlers are registered
for a particular thread and will always execute in that thread.  If
you don't specify a thread, as in (sigaction SIGINT handler), the
handler is registered for the calling thread.

POSIX specifies that a POSIX signal is delivered to a random thread
that has not blocked that signal.  On Linux, a thread is really a
process with its own PID and since signals are delivered to a specific
PID, they are in effect delivered to specific threads (or process
groups -> thread groups).  For example, a SIGINT handler is executed
in all threads of a process since the whole process group is signalled
by the terminal driver.

That is, signals-plus-threads are quite nasty on Linux.  I think we
should have a dedicated signal handling thread that polls for signals
and marks the relevant system asyncs when they arrive.

(More later.)


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Warning: Unstable POSIX threads support comitted to CVS

[Mikael Djurfeldt]

Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:

> Mikael Djurfeldt <djurfeldt@nada.kth.se> writes:
>
>> It is very irritating that signals are delivered to whatever thread
>> happens to run for the moment.
>
> Do you refer to the execution of POSIX signal handlers or to the
> execution of Scheme signal handlers?

With "delivered" I'm thinking of "end-point" delivery, that is
execution of Scheme signal handlers.  I'm thinking of channeling all
signals to a particular target thread (which becomes the one to run
its handlers until the target is switched).

> That is, signals-plus-threads are quite nasty on Linux.  I think we
> should have a dedicated signal handling thread that polls for signals
> and marks the relevant system asyncs when they arrive.

That sounds like a good solution.  Are there particular reasons why a
dedicated thread is needed rather than that an arbitrary POSIX signal
handler of an arbitrary receives the signal sets the asyncs of the
"foreground" thread?

I guess one such reason could be that we, in that case, could block
signals for all threads except the signal one, with the benefit that a
particular signal is only received "once" (rather than getting a
"barrage" of async marks at asyncronous points in time), right?

M


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel