[ODE] Ideas for threading ODE...
cr88192 at hotmail.com
Sun Aug 21 10:13:10 MST 2005
----- 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.
> 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
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
(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.
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
btw (plug), I have a few shots from my personal physics engine project on
the top of the site:
imo, the general behavior of my engine is still a bit worse than ode, this
is more a personal project for the time being...
> ODE mailing list
> ODE at q12.org
More information about the ODE