On Thu, 20 Sep 2012 07:39:29 -0400 Peter Relson <[email protected]> wrote:
:>>From my read of the doc it appears that TS only serializes with other :>code :>>equally doing TS. I don't see how non-TS code running a linked-list is :>>protected if the TS code removes an item from the list. :>But it is. The point really is that the transactional remover cannot :>remove :>while the runner is running through that part of the queue because the :>runner is accessing data for "read" which conflicts with the remover's :>accessing of the same data for "write". Once the runner is beyond that :>point :>(or if it has not yet gotten up to that point) the removal can occur, so :>when the runner gets there it will find the update already done (or if it :>is beyond, it will not care that an earlier part of the queue has been :>changed). I am not sure that I understand. Non-TS is running a linked list. As it fetches the pointer to P22 from P21 it is interrupted. TS code runs, and attempts to set the forward pointer from P21 to P23 and attempts to reuse the P22 area for a different use. Does the TS routine receive a failure? Or is the non-TS code unprotected and when it resumes it will attempt to use P22 which is now a completely different block? -- Binyamin Dissen <[email protected]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies.
