That wasn't my point. My point was that there is no return channel.
If you want to know when your write is done, you have to use a lock
or a memory barrier. Both are very expensive.
Barriers of synchronisation are a little expensive (one of the main
drawbacks with a too restricted way of co
But broadcasting is a form of message-passing too!
That wasn't my point. My point was that there is no return channel.
If you want to know when your write is done, you have to use a lock
or a memory barrier. Both are very expensive.
As I said, it's a matter of abstraction level. My point is:
On Wednesday 28 May 2008 12:18:37 Damien Doligez wrote:
> On 2008-05-27, at 11:34, Martin Berger wrote:
> >>> Here I disagree. Shared memory concurrency is a specific form
> >>> of message passing: Writing to a memory cell is in fact sending
> >>> a message to that cell carrying two items, the new
On 2008-05-27, at 11:34, Martin Berger wrote:
Here I disagree. Shared memory concurrency is a specific form
of message passing: Writing to a memory cell is in fact sending
a message to that cell carrying two items, the new value and a
return channel that is used to inform the writer that sendi
Am Mittwoch, den 21.05.2008, 09:06 +0100 schrieb Martin Berger:
> Here I disagree. Shared memory concurrency is a specific form
> of message passing: Writing to a memory cell is in fact sending
> a message to that cell carrying two items, the new value and a
> return channel that is used to infor
Ulf Wigner wrote:
Going back to Jon's observation that you cannot exploit
multicore with event-based programming, I'm inclined to
agree, even though I think that message-passing concurrency
is quite suitable for making use of multiple cores (albeit
addressing a wholly different problem from data
In short, with monadic threads, you can safely invoke non-concurrent
code from concurrent code. (The inverse
can be dangerous - but you usually don't do this anyway since you will
end up optaining an 'a Lwt.t).
In my experience that rarely works, in the sense of scaling to code of
significant
Gerd Stolpmann wrote:
I cannot agree. Just use Ocamlnet! Or other libraries doing it for you.
OK I was speaking carelessly. Of course one can use libraries for
e.g. event-handling.
On the contrary: Shared memory parallelization has the fundamental
disadvantage that you cannot reason about it
David Teller wrote:
IIRC, there are already type systems which may prevent deadlocks in
pi-calculus.
This is true but (1) these typing systems are quite complicated
and it will take heroic educational efforts to push such
new typing systems into programming mainstream; (2) these typing
systems
IIRC, there are already type systems which may prevent deadlocks in
pi-calculus. And since pi-calculus is essentially the base for
CML/OCaml's Event/lwt (I'm not 100% sure for lwt), my guess is that it
shouldn't be too hard to get them to work for purely functional threaded
code. The missing step w
Gerd Stolpmann skrev:
This is simply nonsense. Different concurrency techniques
> have different problems.
True.
> For example, in event
> handling-based concurrency you do not need locks, hence
> you cannot run into deadlocks.
Yes you can. We've even had to write design rules to this
effect
Hi all,
> i am under the impression that STM is harder to optimize since
> generally you don't know what the transactions collided on. whereas
> with a "hot lock" you can see precisely what code uses that lock and
> what it locks.
I'm not so sure... In fact, my work in the past 4 months has b
> If the answer is STM, please show me some non-trivial application that
> uses it, preferably
> in an impure language.
yes, that would be interesting to see. presumably the example would
have to come from Haskell, Clojure, or classically some SQL database?
i am under the impression that STM is ha
On Mon, May 19, 2008 at 11:47 PM, Jon Harrop <[EMAIL PROTECTED]> wrote:
>
> There are two problems with what you wrote in this context:
>
> 1. You are replying to a thread about shared-memory parallelism with a
> discussion of sequential concurrency, which is completely different.
>
> 2. You keep s
On Monday 19 May 2008 13:24:26 Berke Durak wrote:
> > > > Similarly, avoiding threads removes concurrency bugs...
>
> Avoiding threads means to me
> ...
> Avoiding threads almost eliminates consistency bugs
> ...
> If you avoid threads
> ...
There are two problems with what you wrote in this conte
On Monday 19 May 2008 15:09:04 Gerd Stolpmann wrote:
> On the contrary: Shared memory parallelization has the fundamental
> disadvantage that you cannot reason about it,
I have been reasoning about shared memory parallel programs for many years.
> and so the only way of checking the quality of th
On Mon, May 19, 2008 at 04:09:04PM +0200, Gerd Stolpmann wrote:
> This is simply nonsense. Different concurrency techniques have different
> problems. For example, in event handling-based concurrency you do not
> need locks, hence you cannot run into deadlocks.
Mostly. You do however need to pay
Am Montag, den 19.05.2008, 12:45 +0100 schrieb Martin Berger:
> Jon Harrop wrote:
>
> >> Similarly, avoiding threads removes concurrency bugs...
>
> > I don't believe you have removed any concurrency bugs. I think you just
> > pushed
> > them around a bit.
>
> I couldn't agree more. If you 'a
On Mon, May 19, 2008 at 1:45 PM, Martin Berger <[EMAIL PROTECTED]>
wrote:
> Jon Harrop wrote:
>
> Similarly, avoiding threads removes concurrency bugs...
>>>
>>
> I don't believe you have removed any concurrency bugs. I think you just
>> pushed them around a bit.
>>
>
> I couldn't agree more. If
Jon Harrop wrote:
Similarly, avoiding threads removes concurrency bugs...
I don't believe you have removed any concurrency bugs. I think you just pushed
them around a bit.
I couldn't agree more. If you 'avoid' concurrency by writing your own
'sequential' event handling code, you have not re
On Sunday 18 May 2008 09:39:15 Berke Durak wrote:> On Sun, May 18, 2008 at
12:03 AM, Jon Harrop <[EMAIL PROTECTED]> wrote:
> > Avoiding threads does not improve the safety of the language, it simply
> > degrades the capabilities of the language.
>
> Avoiding threads is like avoiding malloc() in a
21 matches
Mail list logo
