|
From: Julian S. <js...@ac...> - 2013-06-20 13:39:26
|
On 06/20/2013 02:15 PM, Josef Weidendorfer wrote: > But the code added by VG + > tool (just assume cache simulation) will raise the probability for > transaction failure significantly. Yes .. I agree with that. > And doing a rollback + failure path > is slower than doing the failure path from the beginning. So (1) may > not be a bad option at all. OK, worth a try. At least it gives us an ultra-simple baseline implementation. I expect to have a Haswell box to try with, soon. That's Intel-specific, though. The question of whether we can fit Power/s390 into the same framework is also important. > What about > (3) if XBEGIN/XEND is found in the same SB, remove them. As VG is > serializing threads, there is no way for a conflict within a SB anyway. OK for now, but if we continue Philippe Waroquiers' work on multithreaded Valgrind, then that serialization might go away one day. > PS: Using TM ourself should be a very nice solution to make memcheck > fast when we remove serializing of threads at one point. The move > forward here would be to let the tool decide whether VG core should > do serialization or not. If TM is not available, memcheck would > go with thread serialization as now. Hmm, interesting. Some time earlier this year I worked out most of the details for making memcheck multithreaded without using TM, and posted the details to the list (I think). Philippe points out though that we will in any case need to retain the ability to serialize so as not to force tool authors to completely rewrite tools for multithreaded operation. J |