That's the whole point of the "for each" not using ( or even providing ) a counter. Something I was put right on by RS a while back when I (mistakenly) put in a request to have RB provide the internal loop counter in For Each to the program on request.
For Each is ideal for MP - let RB handle how many of the "set" get handled by each processor. As long as no element gets handled more than once there should be no problem. The only assumption being that the processing done in the loop doesn't itself introduce a "sequential" element - but then that's down to the programmer. In parallel programming, regardless of add-ons to the language, the programmer is always going to have to bear the final responsibility to make sure MP problems don't arise, just as one has to do if programming for threads and semaphores. Other languages such as C have had MP add-ons available by third parties. There are also examples of languages taking on these issues - such as Occam. I think any way RB can make itself more appealing to professional programmers can only be a good thing. Going after the corporate IT market is very hard to justfy on some ways since other tools have that ground so well covered on the Windows platform. So to add language constructs for multiple processors, real-time, DSP processing, the scientific market, and other niche programming areas makes sense to me. Basically ( no pun intended ) any way that RS can entice programmers away from programming in C++, Fortran, Java etc has to be a good thing. On 2/9/06 03:20, "Joe Huber" <[EMAIL PROTECTED]> wrote: > If it were possible to have multiple > "for each" cases running at the same time on separate processors > there would be some very thorny problems about coherency of local > variables used within the for each loop. _______________________________________________ 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>
