|
From: Josef W. <Jos...@gm...> - 2013-07-01 17:25:39
|
Am 29.06.2013 01:06, schrieb Eliot Moss: > Two quick comments: > > 1. *Some* PPC txns are expected to complete if tried repeatedly, and thus will not have a failure path. Hmm. If such transactions are ensured to fall into one SB translation, we could add a flag "execute this translation only in thread-serializing mode", and we can remove the transaction instructions, as it will always succeed. If larger transactions are expected to always succeed after some number of retries, I do not see an easy solution, as any kind of locking (and above serialization will use locks) may result in deadlocks. > 2. At least on x86 and maybe on PPC some status bits indicating failure and its cause need to be set appropriately when going to the failure path. I would assume that there always is a flag for something like "resource overflow"? In the hope that the failure path does not retry the same transaction again. Josef > > Regards - Eliot Moss > Sent via BlackBerry > > -----Original Message----- > From: "Carl E. Love" <ce...@li...> > Date: Fri, 28 Jun 2013 15:37:52 > To: Julian Seward<js...@ac...> > Cc: <val...@li...> > Subject: Re: [Valgrind-developers] Transactional memory implementation input > > On Fri, 2013-06-28 at 22:16 +0200, Julian Seward wrote: >> Hi Carl, >> >>> would work or not work in Valgrind for the power instructions. Anyway, >>> any input on the specifics of how I push the simulated execution >>> directly to the failure path would be helpful. Thanks. >> >> I don't know the specifics of the Power instructions, so I can't answer >> that directly. But I can tell you what the idea was for the Intel >> instructions -- maybe that would help. >> >> (IIRC) the Intel instructions are >> >> XBEGIN %reg -- begin a transaction. >> -- %reg holds the failure-path address >> >> XEND -- finish the most recently XBEGIN'd transaction >> >> So the idea is very simple: translate XBEGIN %reg as if it was >> simply a jump to (the code address in) %reg. Does that help? > > So basically you will unconditionally take the failure path which > presumably is the code to handle the transaction in a non-transactional > way, i.e. to obtain the necessary lock do the operations and then > release the lock. > >>From what I understand of the power implementation (I have some > questions for the IBM compiler people) is that the instruction following > the tbegin will be a branch instruction with the address of the failure > path. So I guess we could do something similar. However I have some > concerns. One concern is, what guarantee do we have that the outcome of > the failure path would be functionally equivalent to the transactional > path? Specifically, did the programmer do the same operations under the > appropriate data lock to guarantee the code sequence is executed > atomically and thus generated the same result?. Seems like we are at > the mercy of whatever the programmer chooses to do in the case of a > failure. I need to chat with our compiler people about that question. > I guess in theory the programmer could chose throw up his hands and just > call exit(1) if the transaction failed. In that case, Valgrind would > never be able to reproduce a successful run of the program on real > hardware where there was no TM issues during the run. Maybe I am still > missing a lot here. Like I said, I am just starting to dive into this > and understand all the issues and ramifications. > >> >> J >> > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |