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.
Shouldn't it work to pass -M --make? Or, hmm, maybe -M isn't
generating enough dependencies - like, it seems that it should
generate a dependency for the final output file specified with -o
but it isn't...
Frederik
On Wed, Dec 07, 2005 at 11:34:55AM -, Simon Marlow wrote:
On 04 December
Does this depend on a certain version of gcc?
$ ghc -M --make Matrix.hs -o matrix
Chasing modules from: Matrix.hs
[1 of 2] Compiling Fu.Prepose ( Fu/Prepose.hs, Fu/Prepose.o )
ghc-6.5.20051207: could not execute: gcc-3.4.3
I'm wondering why it is
10 matches
Mail list logo
