Simon Marlow [EMAIL PROTECTED] writes:
In the general case, for some arbitrary
actions between the write and the read (excluding another write of
course), there is no guarantee that the IORef remains unmodified.
This is an analysis that's performed all the time
On Wed, Dec 07, 2005 at 04:45:52PM +, Tony Finch wrote:
The following paper seems relevant to this thread. Although it's written
in the context of C and C++, it's relevant to any language that combines
pre-emptive threads and imperative features.
On 07 December 2005 19:57, Claus Reinke wrote:
there seem to be two issues here - can we agree on that at least?
1) scheduling non-sequential programs on sequential processors
i wasn't arguing that the scheduler should realise all possible
interleavings at once. the issue i was referring
On Thu, 2005-12-08 at 09:40 +, Simon Marlow wrote:
On 07 December 2005 19:57, Claus Reinke wrote:
there seem to be two issues here - can we agree on that at least?
1) scheduling non-sequential programs on sequential processors
i wasn't arguing that the scheduler should realise
On 08 December 2005 09:40, Simon Marlow wrote:
If you share IORefs between threads and run on a multiprocessor, you
are at the mercy of both sequential optimisations and your
architecture's memory consistency guarantees. In other words, don't
do it. Use communication primitives that have
If you share IORefs between threads and run on a multiprocessor, you
are at the mercy of both sequential optimisations and your
architecture's memory consistency guarantees. In other words, don't
do it. Use communication primitives that have strong properties in a
multi-threaded setting.
I
Simon,
Don't worry, your implementation (and any implementation)
has strong fairness. Just run it enough times that the
hardware fails in the way peoplewant. ;)
Jest aside, I'm totally on your side in this discussion.
Asking an implementation to promise to generate all possible
interleavings
On Dec 8, 2005, at 5:15 AM, Seth Kurtzberg wrote:
[Discussion of the appropriate role of fairness.]
The fundamental requirement is the same for all languages, I believe;
the concurrently executing threads must produce a system state that is
identical to _one_ system state which would be
On 08 December 2005 11:52, Claus Reinke wrote:
is every MVar access is a synchronisation point (in terms of memory
update propagation between threads, not just in terms of thread
interaction)?
Yes, it is. On a multiprocessor every MVar operation performs a full
memory barrier internally.
Talk of uniqueness and so forth on the various Haskell mailing lists
causes me to wonder: with so much imperative code being written in
Haskell these days, to what extent is / should GHC perform standard
imperative optimizations? A few things come to mind:
- Fetch elimination for
Jan-Willem Maessen [EMAIL PROTECTED] writes:
- Fetch elimination for imperative reads:
writeIORef r e acts readIORef r
=== writeIORef r e acts return e
This transformation is valid only on single-threaded systems.
If there is any possibility of an IORef being shared across
On 07 December 2005 13:38, Malcolm Wallace wrote:
Jan-Willem Maessen [EMAIL PROTECTED] writes:
- Fetch elimination for imperative reads:
writeIORef r e acts readIORef r
=== writeIORef r e acts return e
This transformation is valid only on single-threaded systems.
If there
|- Fetch elimination for imperative reads:
| writeIORef r e acts readIORef r
| === writeIORef r e acts return e
|
| This transformation is valid only on single-threaded systems.
| If there is any possibility of an IORef being shared across threads,
| you are out of luck.
|
On Wed, Dec 07, 2005 at 02:15:24PM -, Simon Marlow wrote:
On 07 December 2005 13:38, Malcolm Wallace wrote:
Jan-Willem Maessen [EMAIL PROTECTED] writes:
- Fetch elimination for imperative reads:
writeIORef r e acts readIORef r
=== writeIORef r e acts return e
On 07 December 2005 15:21, Claus Reinke wrote:
(assuming 'acts' doesn't modify 'r').
this remark is the problem.
No, Jan's transformation is correct even in a multithreaded setting.
It might eliminate some possible outcomes from a non-deterministic
program, but that's ok. There's no
On 07 December 2005 15:14, Ian Lynagh wrote:
On Wed, Dec 07, 2005 at 02:15:24PM -, Simon Marlow wrote:
On 07 December 2005 13:38, Malcolm Wallace wrote:
Jan-Willem Maessen [EMAIL PROTECTED] writes:
- Fetch elimination for imperative reads:
writeIORef r e acts readIORef r
Simon Marlow [EMAIL PROTECTED] writes:
I should have said that if 'acts' blocks, then the transformation is
invalid.
Well that is exactly what I was assuming when I said that the
transformation is invalid. In the general case, for some arbitrary
actions between the write and the read
The following paper seems relevant to this thread. Although it's written
in the context of C and C++, it's relevant to any language that combines
pre-emptive threads and imperative features.
http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf
Tony.
--
f.a.n.finch [EMAIL PROTECTED]
On 07 December 2005 16:38, Malcolm Wallace wrote:
Simon Marlow [EMAIL PROTECTED] writes:
I should have said that if 'acts' blocks, then the transformation is
invalid.
Well that is exactly what I was assuming when I said that the
transformation is invalid. In the general case, for some
On Dec 7, 2005, at 12:05 PM, Simon Marlow wrote:
On 07 December 2005 16:38, Malcolm Wallace wrote:
Simon Marlow [EMAIL PROTECTED] writes:
I should have said that if 'acts' blocks, then the transformation is
invalid.
Well that is exactly what I was assuming when I said that the
On Wed, 7 Dec 2005, Robert Dockins wrote:
What exactly are the semantics of C programs and why do we believe that
C compilers are correct?
With regards to threading, the semantics are undefined and the compilers
are subtly broken :-)
Tony.
--
f.a.n.finch [EMAIL PROTECTED] http://dotat.at/
[previously sent by mistake to Simon only - new para at end]
Simon Marlow [EMAIL PROTECTED] writes:
Now, take the original program, but change the creation of m2 to
newMVar (), i.e. m2 starts off full. Is the transformation valid now?
Well maybe, because in some interleavings acts does not
there seem to be two issues here - can we agree on that at least?
1) scheduling non-sequential programs on sequential processors
i wasn't arguing that the scheduler should realise all possible
interleavings at once. the issue i was referring to is known as
fairness in concurrent systems
Tony Finch [EMAIL PROTECTED] writes:
On Wed, 7 Dec 2005, Robert Dockins wrote:
What exactly are the semantics of C programs and why do we believe that
C compilers are correct?
With regards to threading, the semantics are undefined and the compilers
are subtly broken :-)
Just have a look
On Wed, Dec 07, 2005 at 08:30:36AM -0500, Jan-Willem Maessen wrote:
What say others? Is there a need yet? (I don't honestly know the
answer!)
Although I don't think impertive optimizations at this high of a level
will benefit much for how much they cost, after the code has been
processed
On Wed, Dec 07, 2005 at 05:05:58PM -, Simon Marlow wrote:
No, that is exactly what I disagree with. Faced with non-derministic
semantics, the compiler does *not* have to preserve all possible
outcomes. In other words, it does not have to assume that an IORef can
be modified between any
On Wed, Dec 07, 2005 at 05:36:09PM +, Malcolm Wallace wrote:
My expectation is that the config data /will/ have been changed by
some other GUI thread. Surely it cannot be OK for the compiler to
silently deliver the original unchanged data here - it goes against
the programmer's intention.
Yup. this is exactly why C has the 'volatile' keyword. variables that
are declared volatile will always be read and written to memory and
never stored in a register because they could be modified by external
interrupts or threads. If every varibale were considered volatile
everything would be
On Thu, Dec 08, 2005 at 12:17:36AM -, Claus Reinke wrote:
ps does your later email imply that you suggest IORef/MVar as
the non-volatile/volative separation? i'd rather see non-thread-
local IORefs phased out of ch..
yeah. exactly. thread local storage is also quite expensive
Oh, dear, a brief mail with a high-level view of optimization seems
to have touched off some confusion about concurrency. I wasn't
thinking about concurrency at all when I wrote my original message,
but there seem to be some major misconceptions in the ensuing
discussion, which I'd like
30 matches
Mail list logo
