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 20:27:01 -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> <0FE2A07A-841A-4C6A-92A8-878E7F9CEEBB at inspiringapps dot com> <77124270805301112ja025ec1i5295f790cf52d33b at mail dot gmail dot com> <A05D221B-75B8-4EBA-9ABC-BF8CB8008802 at great-white-software dot com> <BF2CEA6C-538E-4AB9-BB8E-F54D1B8335EA at freaksw dot com>
On May 30, 2008, at 6:27 PM, Seth Willits wrote:

> On May 30, 2008, at 7:18 AM, Joe Strout wrote:
>
>>> A lot of messages on this list claimed about the fact that RB does
>>> not use more than one processor (or one core) at a time. it is
>>> incredible and unacceptable !!
>>
>> Get over it.  Preemptive multitasking is, in general, very bad mojo.
>> If you access ANY functions that are not thread-safe .... then
>> your program will have obscure bugs that will crop up in
>> odd circumstances after your software is released.
>
> And yet all those developers (including myself) are able to work
> within the limitations fine.
>
> My interpretation of this answer totally boiled down to "you're too
> naiive to understand how bad threads are." Arguing that for 99% of the
> REALbasic's customers the cooperative model is just fine, or that it's
> simply too big of a time and cost tradeoff to make the core
> foundations of the framework thread-safe, is one thing, but to say
> "it's too hard and you're going to fail" is rather silly.
>
> Just because they're not trivial to use seems like a poor argument to
> not have them.


I've been doing multi-processor programming for 20 years, and even  
today I still sometimes make mistakes.

Multi-processing is a lot more difficult to design and prove, since  
the only times that you have any guarantees are launch, end, and  
explicit synchronization primitives.

-- 
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>