Ben wrote:
perhaps it is too late to suggest things for GSOC --
but stephen tetley on a different thread pointed at aaron turon's
work, which there's a very interesting new concurrency framework he
calls reagents which seems to give the best of all worlds : it is
declarative and compositional
@haskell.org
Subject: Re: [Haskell-cafe] Google Summer of Code - Lock-free data structures
Florian Hartwig wrote:
Heinrich Apfelmus wrote:
So while the two are related, CAS is a machine primitive that works
for a single operation and on a single word while STM is a software
abstraction
Ben midfi...@gmail.com writes:
perhaps it is too late to suggest things for GSOC --
but stephen tetley on a different thread pointed at aaron turon's
work, which there's a very interesting new concurrency framework he
calls reagents which seems to give the best of all worlds : it is
+1 -- the reagents model is interesting and it would be good to see a
Haskell implementation.
On Thu, Apr 5, 2012 at 3:05 PM, Ben Gamari bgamari.f...@gmail.com wrote:
Ben midfi...@gmail.com writes:
perhaps it is too late to suggest things for GSOC --
but stephen tetley on a different
On 3/30/12 4:27 AM, Krzysztof Skrzętnicki wrote:
You mention benchmarking TChans: one particular problem with TChans and
Chans is that they are unbounded. If the producers outpace consumers it
soon ends with memory exhaustion.
If that's the case, then you should consider TBChan[1] which is a
Hi,
I was interested in Distruptor few months ago and started to write a
Haskell implementation. Soon I discovered the lack of native CAS operations
and abandoned project for a while. I don't really have time to develop it
further right now, but the code is available:
Florian Hartwig wrote:
Hi everyone,
I would like to do the GSoC project outlined in
http://hackage.haskell.org/trac/summer-of-code/ticket/1608
One of Haskell's great strengths is its support for all kinds of concurrent
and parallel programmming, so I think that the Haskell ecosystem would
Though of course you can implement CAS in terms of STM, CAS is much
more low-level and will probably be many times (though not
asymptotically) faster.
On Thu, Mar 29, 2012 at 12:01 PM, Heinrich Apfelmus
apfel...@quantentunnel.de wrote:
Florian Hartwig wrote:
Hi everyone,
I would like to do
On 29 March 2012 05:57, Ryan Newton rrnew...@gmail.com wrote:
I just read in your proposal that you started looking into the casMutArray#
issue as well. How far have you gotten with that? Do you want to work on
this together a bit?
I've got an implementation of a casArray# primop that
On 29 March 2012 at 12:01 PM, Heinrich Apfelmus
apfelmus at quantentunnel.de wrote:
Since I don't know much about concurrency, I have a simple question: what is
the difference between atomic compare-and-swap and software transactional
memory? Both are lock-free?
Well, terminology-wise it would
Florian Hartwig wrote:
Heinrich Apfelmus wrote:
So while the two are related, CAS is a machine primitive that works
for a single operation and on a single word while STM is a software
abstraction that isolates sequences of operations on multiple memory
locations from each other.
Is it
On Thu, Mar 29, 2012 at 6:57 AM, Ryan Newton rrnew...@gmail.com wrote:
The ByteArray versions will be more annoying, requiring more variations,
but they are also less essential, because the user can always use
ForeignPtr and bits-atomic in this case, and I believe for our concurrent
data
On Thu, Mar 29, 2012 at 9:01 AM, Gregory Collins g...@gregorycollins.netwrote:
On Thu, Mar 29, 2012 at 6:57 AM, Ryan Newton rrnew...@gmail.com wrote:
The ByteArray versions will be more annoying, requiring more variations,
but they are also less essential, because the user can always use
I think so. Atomically reading and writing a single memory location
(which CAS does) is just a very simple transaction. But using a CAS
instruction should be more efficient, since STM has to maintain a
transaction log and commit transactions, which creates some overhead.
Ah, I see. In that
Of Heinrich Apfelmus
Sent: 29 March 2012 13:30
To: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Google Summer of Code - Lock-free data structures
Florian Hartwig wrote:
Heinrich Apfelmus wrote:
So while the two are related, CAS is a machine primitive that works
for a single operation
Slightly related: I think it would be interesting to compare a
Disruptor-based concurrency communications mechanism and compare it to
e.g. TChans
1. Disruptor - http://code.google.com/p/disruptor/
From: Ryan Newton rrnew...@gmail.com
I think so. Atomically reading and writing a single memory
Hi again,
I just submitted my proposal on the GSoC website. You can find it here:
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/florianhartwig/1
I would be very grateful if someone could read over it and tell me if
it makes sense and if/how it could be improved.
Cheers,
GHC already has a CAS primitive on MutVar#, it just needs to be extended
to MutableArray# and MutableByteArray# (at all of the bit-widths the CAS
instruction would support, e.g. see readWordXxArray# in
http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-prim-0.2.0.0/GHC-Prim.html).
The
On Tue, Mar 20, 2012 at 2:53 AM, Florian Hartwig
florian.j.hart...@gmail.com wrote:
On 19 March 2012 11:46, Ryan Newton rrnew...@gmail.com wrote:
As Adam Foltzer mentioned in the trac ticket a really good structure
would
be the concurrent bags from this paper:
A lock-free concurrent queue alone would be worth a summer project IMO.
G
On Mon, Mar 19, 2012 at 3:25 AM, Florian Hartwig
florian.j.hart...@gmail.com wrote:
On 19 March 2012 00:59, Chris Smith cdsm...@gmail.com wrote:
On Mar 18, 2012 6:39 PM, Florian Hartwig florian.j.hart...@gmail.com
On 19 March 2012 09:56, Gregory Collins g...@gregorycollins.net wrote:
A lock-free concurrent queue alone would be worth a summer project IMO.
G
Ryan Newton is already doing that
(https://github.com/rrnewton/haskell-lockfree-queue).
___
Haskell-Cafe
The MichaelScott lockefree queues in that repository pass tests and should
work. Additional stress testing and feedback would be appreciated. There
are some other queues in the literature that might be worth implementing
but I think other data structures are higher priority.
As Adam Foltzer
On 19 March 2012 11:46, Ryan Newton rrnew...@gmail.com wrote:
As Adam Foltzer mentioned in the trac ticket a really good structure would
be the concurrent bags from this paper:
http://www.cse.chalmers.se/~tsigas/papers/Lock%20Free%20Bag%20SPAA11.pdf
We separately did a C implementation of
Hi everyone,
I would like to do the GSoC project outlined in
http://hackage.haskell.org/trac/summer-of-code/ticket/1608
One of Haskell's great strengths is its support for all kinds of concurrent
and parallel programmming, so I think that the Haskell ecosystem would
benefit from having a wider
On Mar 18, 2012 6:39 PM, Florian Hartwig florian.j.hart...@gmail.com
wrote:
GSoC stretches over 13 weeks. I would estimate that implementing a data
structure, writing tests, benchmarks, documentation etc. should not take
more
than 3 weeks (it is supposed to be full-time work, after all), which
On 19 March 2012 00:59, Chris Smith cdsm...@gmail.com wrote:
On Mar 18, 2012 6:39 PM, Florian Hartwig florian.j.hart...@gmail.com
wrote:
GSoC stretches over 13 weeks. I would estimate that implementing a data
structure, writing tests, benchmarks, documentation etc. should not take
more
than
26 matches
Mail list logo
