RB only uses cooperative threads, which means you total thread
utilization cant exceed 100% cpu. I agree that trying to get rb to
do multiproc magic for us is a bad idea, but i think it's time RB add
a real preemptive thread class to the framework, and do the necessary
work to make the framework safer to call form mpthreads. (you can
build mpthreads via declares now, but so much of rb isn't threadsafe,
you're very limited in what you can do in them.)
mike
--
Mike Woodworth
[EMAIL PROTECTED]
On Nov 8, 2006, at 12:38 PM, Fargo Holiday wrote:
Why would you want a single thread to span CPUs, when that's what
multi-threading is for, and that modern operating systems will
automatically load balance threads between CPUs. I suppose I could
be missing the point, and I didn't even see the original post, but
it strikes me as a concept that has arisen more from a lack of
information than actual need. Want to take advantage of multiple
CPUs, use more than one thread. You don't have to manually tell a
thread to use multiple processors, that's the job of the OS. Keep
in mind that each thread also adds some overhead all on its own, so
you wouldn't want to spawn an inordinate number of them, but that
has a lot more to do with testing and optimizing than adding
anything to RB.
Re-reading the original message that was quoted, I also want to
mention that I think it's asking a lot, as in too much, to have a
For Each loop automatically span processors. Way too easy to end up
with race conditions, massive thread overhead, and I'm sure a bunch
of other problems. If you have an enormous For Each loop, with a
bunch of tasks that do TOTALLY unrelated tasks, then just have
those tasks encapsulated in a thread, and run that thread in your
loop. If you have data operations that rely on the results of
previous data operations, then make sure that you're using some
method of thread syncing, such as a mutex.
If you want some more reading on threads, I'd start here:
http://www.nicemice.net/amc/os-prelim/summaries/intro-threads.var
Then poke about the internet, and I'm sure the other RB posts.
I freely admit I may be totally wrong, but currently I don't think so.
Later,
Fargo
Daniel Stenning wrote:
Just to add - I personally see this feature as being far more
important
than Cocoa in the short term. It is something that many of us
( those of
use that have apps using very processor intensive code ) could
gain from
immediately.
On 8/11/06 15:40, "Daniel Stenning" <[EMAIL PROTECTED]> wrote:
With all the new multiple CPU Mac and PC models available these
days, in
order be able to take any advantage of this in RB we need some
new language
constructs and compiler amendments.
If you think this would be a useful addition to RB in the future
please sign
on to the following feature request posting:
http://www.realsoftware.com/feedback/viewreport.php?
reportid=mkxoxbzc
For example a prime candidate would be to make changes to the thread
facilility, as well as language changes to allow FOR EACH to
spread tasks
across CPUS. Naturally every developer will need to be aware of
and take
account of the limitations and issues surrounding parallel
threading etc,
but at least give us the tools to start using this.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
