This page is part of the web mail archives of SRFI 18 from before July 7th, 2015. The new archives for SRFI 18 contain all messages, not just those from before July 7th, 2015.
The time has come to move closer to a final spec for SRFI-21. Michael has put my latest version of the spec on the web. Please take a look and give me your comments. I would like to finalize in a week or two. Below is a summary of the changes. Marc - There is now an explicit description of the thread states (new, runnable, blocked, and terminated). This makes the spec clearer. - A "specific" field has been added to mutexes and condition variables, which is analogous to the "specific" field of threads. It can be used by the application to attach any data to a mutex or condition variable. In particular this is useful to implement recursive mutexes (an example is provided in the spec). - The specification of fairness, priority, and priority boosts has been improved. - Applying the thread priority boost at thread creation is a bad idea because it can lead to unexpected thread creation delays. For example, consider a monoprocessor system with round-robin scheduling of threads of the same priority, and a thread T0 that tries to create and start N threads T1 to TN that are CPU intensive (no I/O). If T0 has a nonzero thread boost, and it hasn't blocked recently, then as soon as T0 starts T1, T1 will start running and T0 won't get to start T2 until T1's quantum is up. But as soon as T0 starts T2, T2 will start running until its quantum is over and then T1 will run until its quantum is over. So it takes O(N*N) quantums before TN starts running. For this reason the specification was changed so that the thread boost only applies when a thread blocks. - The scheduler's "grace period" to take into account a change in priority (in thread-base-priority-set!, thread-priority-boost-set!, thread-quantum-set!, etc) has been removed. It is just too difficult to specify a useful semantics correctly. - I have removed the restriction on invoking continuations created by other threads, and clarified the interaction with dynamic-wind and the dynamic environment. - The "started thread exception" has been removed. It is an error to start a thread that is not new (i.e. runnable, blocked, or terminated) but there is no good reason for SRFI-21 to say how this error should be reported by the implementation. - (thread-start! t) now returns the thread t. This is convenient to immediately start the thread being created: (let ((t (thread-start! (make-thread (lambda () ...))))) ... do something with t ...)