On Tue, 2009-11-24 at 16:13 -0700, Alex Rousskov wrote:
> For example, I do not think it is a good idea to allow a combination of
> OpenMP, ACE, and something else as a top-level design. Understanding,
> supporting, and tuning such a mix would be a nightmare, IMO.
I think that would be hard, yes.
> See Henrik's email on why it is difficult to use threads at highest
> levels. I am not convinced yet, but I do see Henrik's point, and I
> consider the dangers he cites critical for the right Q1 answer.
> > - If we do *not* permit multiple approaches, then what approach do we
> > want for parallelisation. E.g. a number of long lived threads that take
> > on work, or many transient threads as particular bits of the code need
> > threads. I favour the former (long lived 'worker' threads).
>
> For highest-level models, I do not think that "one job per
> thread/process", "one call per thread/process", or any other "one little
> short-lived something per thread/process" is a good idea.
Neither do I. Short lived things have a high overhead. But consider that
a queue of tasks in a single long lived thread doesn't have the high
overhead of making a new thread or process per item in the queue. Using
ACLs as an example, ACL checking is callback based nearly everywhere; we
could have a thread that does ACL checking and free up the main thread
to continue doing work. Later on, with more auditing we could have
multiple concurrent ACL checking threads.
-Rob
This archive was generated by hypermail 2.2.0 : Wed Nov 25 2009 - 12:00:10 MST