Andrew, Thanks for pointing your finger at it Am 04.08.2010 um 17:48 schrieb Andrew Coppin:
> Frank Kupke wrote: >> Good questions. I am about to write a paper explaining the design of the >> DSTM library in more detail which I will link when available. Please bear >> with me, here. In the meantime please find some shorter answers below. >> > > Well, that was pretty comprehensive. A few questions remain... > >> - If the failure comes up *before* the transaction has been validated ok, it >> is aborted. > > Right. So the transaction rolls back and the application gets an exception? Yes, the transaction aborts and the application gets an exception (see remarks below). > >> - If the failure comes up *after* the transaction has been validated ok, it >> is committed. >> > > So if a TVar goes walkabout in the split second between validate and commit, > the others commit anyway, and then the application gets an exception? Yes. > > In that case, is there a way to determine whether or not the rest of the > transaction completed? Because it looks like you can the same exception > either way, regardless of whether a commit happened or not. Ah, now I see. Excellent point. I was always focussing the commit case which is well designed, I am certain. But, maybe, the abort case above is not. It would probably be better to not only abort but also restart the transaction even in presence of a failure (that is what's being done when there is no failure). I am not quite clear yet about a possible implementation of such a behavior. Currently I'm thinking: Restarting a transaction containing broken TVars will definitely fail again. To avoid that, the validation vote of a broken TVar (i.e. not able to vote any more) should be taken as a valid vote and no exception should be thrown. Eventually every transaction comes to a commit and probably that's the only place where an exception should be thrown. Then the answer to your question is clear, also. Any opinions? > >>> 4. What network transport does this thing use? TCP? UDP? What port numbers? >>> >> DSTM uses TCP communication. It searches dynamically for available ports >> starting at port 60001, using 60000 for the name server. If two nodes are >> running each on a separate machine with a different IP address, chances are >> that both use the same port 60001. If they run on the same machine, most >> likely one will use port 60001 and the other 60002. >> > > Right. So both the nameserver and any clients run on random port numbers? > (Begs the question of how the clients figure out which port a remote > nameserver is on...) Well, not quite. The name server gets a fixed 60000 to make it accessible statically, the others may vary. Their dynamic address is used to label the TVars which then always carry their correct address. > >>> 5. How does it work? Does it spawn a Haskell thread for each machine >>> connection or something? >>> >> Each node spawns a Haskell thread listening to its designated port and >> spawning itself a thread for each accepted TCP communication, i.e. one for >> each foreign node talking to it. Each such thread implements a communication >> line between two threads. I have tried several communication line schemas >> which I will describe in more detail in the paper yet to come... >> > > What impact (if any) does threaded vs non-threaded RTS have? I have done a few tests with threads and could not find a significant difference. But I really did not look deep and thorough enough into it to give a qualified answer. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
