The work arounds for I/O in optimistic STM are exactly the problem. They tried 
to solve it by essentially eliminating the optimism without bringing the 
conveniences of real pessimism, namely direct expression of programs with I/O.

And your quote of the paper is misleading and out of context. The "convenience 
of locks" is specifically referring to the I/O problem, not transactional 
memory. Optimistic STMs are far less convenient to work with than locks when it 
comes to I/O. An STM that provides transactional memory while allowing you to 
express direct I/O with no chance of aborts is a huge win over the current 
state of the art.

Sandro

William ML Leslie <[email protected]> wrote:

>On 19 September 2013 13:03, Sandro Magi <[email protected]> wrote:
>> Optimistic GC will never fly. Abort rates are too high, and the very
>> possibility of aborts makes reasoning about programs with side-effects
>> infeasible.
>
>Abort rates can be high, and this probably will be a scalability
>problem in the future.  I don't really know what you're saying about
>side-effects, though, transactions can't do IO unless they are
>inevitable in most STM systems.
>
>> The only way forward IMO, is either a pessimistic STM which restores
>> reasoning and composition for transactions [1],
>>
>> [1] http://mcg.cs.tau.ac.il/papers/transact2012-pessimistic.pdf
>
>Splork!
>
>For the unprepared:  the abstract for this paper describes a technique
>that programming with it
>
>"is logically as simple as with locks"
>
>-- 
>William Leslie
>
>Notice:
>Likely much of this email is, by the nature of copyright, covered
>under copyright law.  You absolutely may reproduce any part of it in
>accordance with the copyright law of the nation you are reading this
>in.  Any attempt to deny you those rights would be illegal without
>prior contractual agreement.
>_______________________________________________
>bitc-dev mailing list
>[email protected]
>http://www.coyotos.org/mailman/listinfo/bitc-dev

_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to