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.
next prev 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