[ODE] Ideas for threading ODE...

[cr88192]

----- Original Message ----- 
From: "Tyler Streeter" <tylerstreeter at gmail.com>
To: "ode" <ode at q12.org>
Sent: Sunday, August 21, 2005 9:26 AM
Subject: Re: [ODE] Ideas for threading ODE...


>> OpenMP should not be req'd, as it is better to do roll
>> your own threads using pthread library.
>>
>>   Bram
>
> Can you explain this statement?  Why is it better to roll your own
> using pthreads?  I would think OpenMP is better since it is simpler to
> use and works on more platforms.
>
I will respond here as I feel like it...

once in a previous project, I had set things up so that some kinds of work 
could be divided into a number of pieces, which were qued up, and executed 
by worker threads, with any new pieces of work being added back to the 
queue.

of course, this requires special attention (preventing multiple threads from 
grabbing the same item of the queue, or otherwise fouling it up). a mutex 
was used for this.

in the single threaded case, the main thread would keep doing work until all 
work is done, and continue. in the multithreaded case, each worker grabs 
what it needs, does that, and continues until there is no work, in which 
case it will go idle. new work results in triggering idle threads to wake up 
and grab what they can.

now, a platform specific chunk of code can be done for the threading 
backend. this implements the workers, and provides calls for external code 
to add work.

(then the problem became the threads trashing out the memory manager/garbage 
collector, which was never completely dealt with). likewise, on single 
processor computers, threading didn't lead to much benefeit.

later on, I just used plane queues, with a single worker as described above. 
"real" multithreaded code has not really been written since for lack of 
motivation (and the fact that my newer mm/gc is based on basically the same 
design, and would probably need a bit of work to handle threading 
effectively).

(one possible solution to the problem was that of giving each worker a 
seperate heap, and minimalizing data sharing between threads). this, 
however, did not mix well with the "programming model" involved with the 
project of the time.


issue then:
now, one has more of a choice as to the threading model.


I have before considered writing a generalized c interface for this kind of 
thing (probably revolving around callbacks and passing pointers). but, 
likewise, I have not felt much need, most current machines are single 
threaded.



btw (plug), I have a few shots from my personal physics engine project on 
the top of the site:
http://bgb-sys.sourceforge.net/shots.html

imo, the general behavior of my engine is still a bit worse than ode, this 
is more a personal project for the time being...

> Tyler
>
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>