On 16 Jan 2011, at 03:58, Jan-Willem Maessen wrote:
Actually, the first presentation of M-structures is rather older than
that. See Barth, Nikhil, and Arvind's FPCA '91 paper:
http://portal.acm.org/citation.cfm?id=652538
The original formulation was indeed in terms of take and put,
though
On Wed, Jan 12, 2011 at 11:23 AM, Neil Brown nc...@kent.ac.uk wrote:
On 12/01/11 15:53, Edward Z. Yang wrote:
These are interesting, opposed perspectives, and I suspect what would be
good is to treat both situations. I think perhaps what would be good
to put in the introduction is the
I'll try another writeup. Does anyone know where the original papers for
MVars might be?
In my mind, full/empty variables date back to dataflow machines.
But I don't know where I got this idea.
Stefan
___
Haskell-Cafe mailing list
Ok, here is an updated doc patch. I've also added
a substantial introduction section.
diff -rN -u old-base/Control/Concurrent/MVar.hs
new-base/Control/Concurrent/MVar.hs
--- old-base/Control/Concurrent/MVar.hs 2011-01-13 16:26:59.0 +
+++ new-base/Control/Concurrent/MVar.hs
These are interesting, opposed perspectives, and I suspect what would be
good is to treat both situations. I think perhaps what would be good
to put in the introduction is the conceptual model of MVars: that is,
take and put are the fundamental operations, and everything else is
composed of them.
On 12/01/11 15:53, Edward Z. Yang wrote:
These are interesting, opposed perspectives, and I suspect what would be
good is to treat both situations. I think perhaps what would be good
to put in the introduction is the conceptual model of MVars: that is,
take and put are the fundamental
Mitar wrote:
Hi!
On Sat, Dec 25, 2010 at 11:58 AM, Edward Z. Yang ezy...@mit.edu wrote:
I think you're right. A further comment is that you don't really need
stringent timing conditions (which is the only thing I think of when
I hear race) to see another thread grab the mvar underneath
Wasn't that result John Launchbury's? I recalled hearing something similar
as well.
Cheers,
Edward
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Excerpts from Mitar's message of Fri Dec 24 23:18:43 -0500 2010:
I am not sure if this are really race conditions? The point is that
readMVar, withMVar and others do not return until they can return the
value back and after that the value is the same as it was at the
beginning of the call. So
Hi!
On Sat, Dec 25, 2010 at 11:58 AM, Edward Z. Yang ezy...@mit.edu wrote:
I think you're right. A further comment is that you don't really need
stringent timing conditions (which is the only thing I think of when
I hear race) to see another thread grab the mvar underneath
you
Yes, MVars are
Merry Christmas all!
Is it just me, or does the Control.Concurrent.MVar documentation seem a bit
misleading? In particular, we should explicitly note the race conditions
for not just swapMVar but also readMVar, withMVar, modifyMVar_ and modifyMVar,
and clarify that the safety guarantees of the
ezyang:
Merry Christmas all!
Is it just me, or does the Control.Concurrent.MVar documentation seem a bit
misleading? In particular, we should explicitly note the race conditions
for not just swapMVar but also readMVar, withMVar, modifyMVar_ and modifyMVar,
and clarify that the safety
Here is one suggested doc patch. Comments and revisions welcome:
ezy...@javelin:~/Dev/ghc-clean/libraries/base/Control/Concurrent$ darcs
whatsnew -u
hunk ./Control/Concurrent/MVar.hs 59
{-|
This is a combination of 'takeMVar' and 'putMVar'; ie. it takes the value
- from the 'MVar', puts
On Fri, Dec 24, 2010 at 5:32 PM, Edward Z. Yang ezy...@mit.edu wrote:
Merry Christmas all!
Is it just me, or does the Control.Concurrent.MVar documentation seem a bit
misleading? In particular, we should explicitly note the race conditions
for not just swapMVar but also readMVar, withMVar,
Hi!
On Sat, Dec 25, 2010 at 2:32 AM, Edward Z. Yang ezy...@mit.edu wrote:
In particular, we should explicitly note the race conditions
for not just swapMVar but also readMVar, withMVar, modifyMVar_ and modifyMVar,
I am not sure if this are really race conditions? The point is that
readMVar,
15 matches
Mail list logo
