Andreas Beck wrote:
> A few thoughts about multithreading LibGGi3d:
> > But IHMO the way of implementation the module concept is bad. I think the
> > modules should be self-running programms and they use shared memory for
> > communication. This will have this advantages:
> > - better scaling on SMP-machines
> And worse on non-SMP, or if the number of processes exceeds the number of
> CPUs. Note, that you will often have to switch between modules very rapidly
> to avoid having large queues that will introduce large latencies, which is
> quite as bad as slow rendering for 3D stuff. Thus scheduling overhead will
> get pretty large.

You are right and that was exactly the motivation behind my thread pool suggestion.
If you use a task queue you can use whatever number of threads you want, inclusively 
Pushing/popping tasks in/out the queue is a very fast operation (can made to be fast)
so I think it is really what you want. You could use a macro (since you probably
insist on writing in C, not C++) for the locking/unlocking which simply maps to a
noop in case of no concurrency.

> So IMHO one should rather _avoid_ multithreading, except for _large_
> independent tasks. The natural way to do this is in the user program, like
> separating input, scene calculation and rendering.

Of course, the best strategy to divide the whole thing into elementary tasks is
the tricky part since it involves intimate knowledge of the h/w resources to keep
contention low.

> I'd say go like LibGGI: Support threads if available, but don't require
> them.

Again, with my thread pool suggestion, you could fall back to a single threaded
program whenever you either have a single CPU or the OS you are compiling for doesn't
support threading well. The decision about the numbers of threads can be made either
at compile time or at run time.

Stefan Seefeld
Departement de Physique
Universite de Montreal


      ...ich hab' noch einen Koffer in Berlin...

Reply via email to