Re: Threadpool with priority version 1.1 ...

[Warren <ve3wwg@gmail.com>]

Maciej Sobczak expounded in
news:7b059d0f-791b-4ac9-bf64-c50448ec99f7@b30g2000yqd.googlegroups.com: 
..
> The difference between application and OS is in the amount of
> knowledge about what the software will do and applications tend to
> know more than OS in this aspect.

Yes.

> That is why it is more realistic to have applications allocating their
> resources during initialization phase than to see that at the OS
> level.

I would generally agree with that, unless the cost of resource
management was cleverly reduced.

> I'm not a big fan of programs that allocate and deallocate the same
> resource repeatedly - this is an obvious candidate for caching and
> object reuse, where the cost of allocation is amortized.

As a general principle this is right. But memory is another
resource that sometimes needs careful management. With only
1 thread, you have a heap growing up to the stack and a stack
that grows towards the heap. Either stack or heap can be huge
(potentially at least), as long as both are not at the same
time (overlapping).

The moment you add 1 [additional] thread, you've now drawn
the line in the sand for the lowest existing stack, and
putting a smaller limit on it.

This disadvantage is ok for probably most threaded programs,
but perhaps not for a video rendering program that might 
hog resources on both heap and stack sides at differing
times.

In the end, the application programmer must plan this out,
but this is a limitation that I dislike about our current
execution environments. I suppose, just increasing the
size of your VM address space, postpones the problem 
until we hit limits again. ;-)

> Fortunately,
> it is not even necessary for a user code to do that - think about a
> caching memory allocator, there are analogies. And the language
> standard does not prevent implementations from reusing physical
> threads, if they are used as implementation foundations for tasks.
> Maciej Sobczak * http://www.inspirel.com

From an efficiency pov, this is all well and good. But
if you want maximum dynamic allocation of heap+stack,
then you might prefer fewer (if any) pre-allocated threads
(implying additional stacks).

Warren