[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] System load

From: Felix Winkelmann
Subject: Re: [Chicken-users] System load
Date: Thu, 16 Jan 2003 16:20:34 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530

Joerg F. Wittenberger wrote:

Easy: have a queue for all threads, remove there only when thread
terminates, one queue for each reason to block (condition variable).
Those are there anyway.  One ready queue, which is just that.  A
pointer into the ready queue for the current thread.  Scheduling
advances this to the cdr of the ready queue of the whole queue, when
at end of list.  Unblocked or new threads to to the head of the ready

Not bad. But what about threads that are blocked for a given time?
Do they also get their own queue?

The scheduler should also set a global variable, which is returned by
(current-time) [or if this is not desirable then call it
(current-timeslice-start)], this safes a few system calls.

The frequency, with which the scheduler is called can not be assumed
identical from context-switch to context-switch, I'm afraid. GC can
(and does) happen too frequently. Compiler-optimizations can reorganize
code substantially (with interrupt-checks moving from one place to
the other).
So this timing method will be *very* inaccurate.

On the other hand getting the time to check for timed out threads is
only needed for mutex-lock!, mutex-unlock!, thread-join! (when a timeout
is given) and for thread-sleep!.

Another global variable keeps the time until the next time event is
going to be delivered.  If the ready queue becomes empty, we wait in
select for that much time.  Otherwise every 2ms do a select without

We could do a little calibration-loop at startup (of the srfi-18 unit)
that computes some base time for a normal time-slice.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]