realbasic-nug
[Top] [All Lists]

Re: Dealing with multi-processor or multi-core

To: REALbasic NUG <realbasic-nug at lists dot realsoftware dot com>
Subject: Re: Dealing with multi-processor or multi-core
From: "Glenn L. Austin" <glenn at austin-home dot com>
Date: Fri, 30 May 2008 07:39:38 -0700
Authentication-results: mx.google.com; spf=pass (google.com: domain of realbasic-nug-bounces at lists dot realsoftware dot com designates 66.116.103.65 as permitted sender) smtp dot mail=realbasic-nug-bounces at lists dot realsoftware dot com
Delivered-to: listarchive at realsoftware dot com
Delivered-to: realbasic-nug at lists dot realsoftware dot com
References: <p06240802c4657bd7c318 at [62 dot 161 dot 36 dot 122]> <41B4C50C-AB85-4975-B2AE-C6A4DD49D787 at inspiringapps dot com> <48400D8C dot 7090301 at chrononomicon dot com>
On May 30, 2008, at 7:22 AM, Bart Silverstrim wrote:

> Joe Strout wrote:
>
>> Get over it.  Preemptive multitasking is, in general, very bad mojo.
>> If you access ANY functions that are not thread-safe (and this would
>> include pretty much the entire framework, as well as many of the OS
>> functions that you use even for simple things like drawing to a
>> window), then your program will have obscure bugs that will crop up  
>> in
>> odd circumstances after your software is released.  The Windows
>> platform layer used to use preemptive threads, and it was a nightmare
>> -- one that ended only when they coded a cooperative multitasking  
>> system like the Mac already had.
>
> Could you elaborate on this? I thought all NT lineage was preemptively
> multitasking, with a Win16 compatibility system for older applications
> that was cooperatively multitasked within itself...?

But the NT scheduler (through XP) absolutely sucked in terms of  
permitting a single process to "starve" other processes.  That has  
been improved with Vista.

>> To make use of multiple processors safely (in ANY language), you need
>> to divide your work into separate processes.  In RB, the best way to
>> do this is via a helper app that you would access via the Shell.   
>> It's
>> not that hard to do, and it's 100% safe.
>
> You're saying design your app to be multiprocess and not  
> multithreaded?


Design it to be multi-processor-aware, and you're far better off than  
multi-threaded.  When you start thinking "multiple processors" you  
start thinking about contention for resources (multiple processors  
attempting to access the same resource) and parallelizing your tasks  
by reducing "sync points" between multiple processes.

Threading (and parallel processing) is something that a lot of people  
want to be able to do, but there are so many pitfalls that most people  
don't get it right.

(I've been designing parallel processing systems since 1987 -- it's  
NOT as easy as it looks!)

-- 
Glenn L. Austin <><
Computer Wizard and Race Car Driver
<glenn at austin-home dot com>
<http://www.austin-home.com/glenn/>


_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>


<Prev in Thread] Current Thread [Next in Thread>