comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Loops and parallel execution
Date: Wed, 26 Jan 2011 15:57:12 -0600
Date: 2011-01-26T15:57:12-06:00	[thread overview]
Message-ID: <ihq5br$ir9$1@munin.nbi.dk> (raw)
In-Reply-To: 4d3eeef7$0$6879$9b4e6d93@newsspool2.arcor-online.net

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:4d3eeef7$0$6879$9b4e6d93@newsspool2.arcor-online.net...
...
> Can this be borrowed from HPF (IIUC)?
> Is pragma Pure (P) sufficient to signal reentrance?

I've thought about such an idea. But it requires restrictions well beyond 
those enforced by pragma Pure. For instance, Pure packages can write 
dereferences of pointers to keep global state. Moreover, there can't be any 
"cheating", which is common in pragma Pure packages.

So there would need to be a new kind of categorization for this. I was 
hoping that we could using the proposed global in/global out categorizations 
to do the job, but those got dropped from Ada 2012.

Also, I think that "no communication" is impractical in most real 
applications. But it is sufficient if the communication is tightly limited 
(via atomic and protected objects, and/or synchronized interfaces - you'll 
need to access global data, just safely). That's another reason why "checked 
global in/global out" is needed.

Finally, like Dmitry, I'm skeptical about fine-grained parallelism buying 
much. Unless there is specific architectural support (something that doesn't 
exist in commonly used processors -- and especially in commonly used target 
OSes/RTOSes), the management overhead will kill any savings on "small" 
expressions. Thread creation is not cheap! The "win" is on larger tasks - 
which means that subprograms - and separately compiled subprograms - have to 
be involved in some way.

My main interest in this technology is to make it much easier to create 
programs that use threads but don't deadlock, livelock, or have dangerous 
use of globals. That seems to require restrictions on what you can do, and 
definitely requires some form of compile-time checking to enforce those 
restrictions. If done usefully, that could be a giant win, as you could use 
sequential reasoning for the majority of your programming and debugging, and 
still get parallelism when useful.

                                 Randy.






  parent reply	other threads:[~2011-01-26 21:57 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-25 15:40 Loops and parallel execution Georg Bauhaus
2011-01-25 16:37 ` Dmitry A. Kazakov
2011-01-25 17:36   ` Georg Bauhaus
2011-01-25 17:38     ` Georg Bauhaus
2011-01-25 21:32     ` Dmitry A. Kazakov
2011-01-25 22:07       ` Georg Bauhaus
2011-01-26  1:31         ` Yannick Duchêne (Hibou57)
2011-01-26  9:04         ` Dmitry A. Kazakov
2011-01-26  1:06       ` Yannick Duchêne (Hibou57)
2011-01-26 10:08         ` Dmitry A. Kazakov
2011-01-31 13:01         ` Paul Colin Gloster
2011-02-06 20:06           ` Yannick Duchêne (Hibou57)
2011-02-07 11:43             ` Nicholas Paul Collin Gloster
2011-01-26  8:46 ` Egil Høvik
2011-01-26 10:47   ` Georg Bauhaus
2011-02-14 23:27     ` Tuck
2011-02-15 21:10       ` Georg Bauhaus
2011-01-26 11:29 ` Peter C. Chapin
2011-01-26 21:57 ` Randy Brukardt [this message]
2011-01-27 23:01   ` tmoran
2011-01-29  0:23     ` Randy Brukardt
2011-02-06 20:10       ` Yannick Duchêne (Hibou57)
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox