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
signature.asc
Description: This is a digitally signed message part
