Re: [boost] "[gsoc] Thread scheduler support for boost"

Subject: Re: [boost] "[gsoc] Thread scheduler support for boost"
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2009-03-25 08:36:12

> However, I thought of your suggested extension of threadpool class
> exploiting processor affinity techniques and it sounds very
> interesting as well but I guess we would run into the same portability
> issues with regard to availability of the lower level API exposing the
> hooks to be able to develop such a facility. Another issue would be to
> qualify and justify how much improvement would this type of
> parallelism enable on top of the instruction level parallelism already
> in place for all modern processors. Although, I would still like to
> find out if you have any concrete lead in mind.

FWIW, processor affinity is supported on many operating systems, so it
shouldn't be problematic to come up with a portable implementation.
Moreover, I believe Oliver already included something like that into his
thread_pool library (see http://tinyurl.com/cqgt5u, file
boost-threadpool.v24.tar.gz).

> I know for sure that there are those hard engineering problems in high
> performance computing domain to ensure QOS guarantees to distributed
> real-time embedded systems. They look into processor utilization
> optimizations in the face of uncertainty of computational load on the
> system. These usually require some kind of mathematical validation of
> the scheme for the system under construction. I guess that would be
> beyond the scope of the GSOC project, given the time frame.

I'm sure that controlling processor affinity is something to consider not
only for real time applications or high end computing. With the rising
number of cores in a chip we need to be able to influence this for everyday
tasks as well. But that's only IHMO.

> M:N type of models would also have the same portability issue as it
> requires changing kernel code as well as the userland code in thread
> library.

You shouldn't shy away of some feature just because Boost requires portable
implementations. Most of the time this is possible to achieve, as modern
OS's have very similar functionality, just exposed using different API's.

Regards Hartmut