Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Horizon68 Newsgroups: comp.programming.threads Subject: Transactional Memory Everywhere: I/O Operations Date: Wed, 3 Oct 2018 12:16:06 -0700 Organization: A noiseless patient Spider Lines: 25 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 3 Oct 2018 19:16:06 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="959e42c0d176d894236c7ab3c097d21d"; logging-data="14218"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/NSiQ9FDYg8gkugkNRnyrlHaICEda1zaY=" User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 Cancel-Lock: sha1:Jin3p3zCNgdJZ44/kni6ocUXqVk= Content-Language: en-US X-Mozilla-News-Host: news://news.eternal-september.org:119 Xref: csiph.com comp.programming.threads:4665 Hello, Transactional Memory Everywhere: I/O Operations One can execute I/O operations within a lock-based critical section, and, at least in principle, from within an RCU read-side critical section. What happens when you attempt to execute an I/O operation from within a transaction? The underlying problem is that transactions may be rolled back, for example, due to conflicts. Roughly speaking, this requires that all operations within any given transaction be idempotent, so that executing the operation twice has the same effect as executing it once. Unfortunately, I/O is in general the prototypical non-idempotent operation, making it difficult to include general I/O operations in transactions. Read more here: https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/Answers/TransactionalMemoryEverywhere/IO.html Thank you, Amine Moulay Ramdane.