RE: [boost] Re: Threads: Other Primitives

From: Darryl Green (green_at_[hidden])
Date: 2002-03-14 06:04:19

> -----Original Message-----
> From: danl_miller [mailto:danl_miller_at_[hidden]]
> > > I think a thread pool would want to use LIFO - it would seem 
> > reasonable to
> > > expect that the dispatch of making a more recently run thread
> ready 
> > would be
> > > faster than a less recently run one (it would be unlikely to be 
> > slower in
> > > any case). I can't think of any other  reason (off hand) for 
> > wanting LIFO. I
> > > must admit that I have never explicitly requested LIFO.
> 
>   Darryl, this applies if there is some form of penalty regarding the
> use of the least-recently-used (LRU) unallocated resource in a pool
> and some sort of economy of using the most-recently-used (MRU)
> unallocated resource in a pool.
> 
>   Regarding this allocation-of-a-thread-from-a-thread-pool topic, I
> can see that one such penalty could arise from the use of virtual
> memory (VM).
> 
>   In RTOSes and in embedded software and in real-time software, VM
> usually falls somewhere in between thoroughly unacceptable and frowned
> upon.  I agree with a LRU/LIFO approach if in a VM OS where there is a
> penalty for demand-paging in (portions of) the LRU thread's
> address-space into core RAM.
> 

Yes, though even embedded systems have caches these days (actually, given
the "nearly 10 years", they probably always have for you? :-). I was also
thinking of trying to make life easier for a multi-processor scheduler
trying to manage processor affinity. I suspect the thread pool concept tends
to be more useful in larger "general purpose" systems anyway (vs. embedded
RTOS envoronments) because threads tend to be heavier and the task-set on
the system is more dynamic. Conversely, the embedded RTOS
environments/real-time systems tend to involve knowing just what the set of
concurrent tasks is and dimensioning things accurately (or more likely
pesimistically) so as to meet its deadlines rather than trying to make the
software adaptive to its execution environment in order to (try to) maximise
performance but without hard deadlines.