From: Vladimir T. <vtz...@gm...> - 2009-02-22 18:22:10
|
On Sun, 22 Feb 2009 19:16:17 +0200, Don Cohen <don...@is...> wrote: > Vladimir Tzankov writes: > > > If the thread finishes - in order to remove it from the list of all > > threads - we will have to scan whether there are refernces to > > it. This is expensive operation and anyway is performed during GC. > Clearly something internally does not work as I expect. > To me the obvious solution was that > - make-thread would add the new thread to the list read by list-threads > - finishing a thread would remove it from that list list-threads returns all threads accessible in the system regardless whether they have finished or not. If you are interested only in running threads there is always (mapcar #'thread-active-p (list-threads)) However while you process the return of this - some of the threads may finish as well. The reason finished threads are included in the list is that there are references to them and/or you may be interested why some of them have terminated. This may be done by inspecting some of special variable bindings (symbol-value-thread sym thread). May be quite helpful sometimes and does not harm anything. > > > I don't see what control over the scheduler has to do with it. > > > Thread-wait seems to make sense if you're willing to busy wait, > > > which might be more reasonable if you include a sleep in the loop. > > See: http://gbbopen.org/hyperdoc/ref-portable-thread-entities.html - > > "What about Process Wait?" > I find the whole page to be very interesting - I was not aware it > existed. However I don't see that it answers the question of what > any of this has to do with control over the scheduler. > > My view is that it has nothing to do with the scheduler. > I think process-wait was (is) a reasonable thing in single cpu > machines. Even with single CPU it is not good at all. thread-wait with some predicate does not assure anything. The OS thread scheduler may preempt the predicate at the middle or after it has returned T but before thread-wait returns. The next scheduled thread may change the whole program state in such a way that predicate is NIL. This will not lead to anything good. without-interrupts does not enforce no preemption with native OS threads. It enforces the form to be executed entirely (what we discuss about unwind-protect cleanup forms) but it can be preempted meanwhile. Of course it is possible to provide something like without-other-threads-running but this is the worst kind of synchronization possible. It is expensive and will not scale. > It occurs to me that, if you view gbbopen portable threads as a > reasonable interface, you might implement it and make it part of > clisp. I plan to provide port for clisp. > I notice in particular that it contains something called > as-atomic-operation, which I gather (let me know if I'm wrong about > this) has the semantics described above -- nothing else can be going > on at the same time. Please check also the comments in: http://gbbopen.org/svn/GBBopen/trunk/source/tools/portable-threads.lisp about ClozureCL and as-atomic-operation (CCL also uses native OS threads). > (BTW, another project I'd love to see is GC implemented as thread(s) > running in parallel with non-gc threads.) Me too. It seems the marking phase can be parallelised. However not sure whether there will be significant increase in performance. > > Whatever thread-state returns - until you process it in meaningful > > way - it may change. > Is thread-state supposed to be related to who-state in some way? No. I did not find good fit/implementation for both of them. Whoever wants something like whostate - can easily implement it. thread-state is not adequate when you can be preempted at any time. |