multithreading in OpenPiton

[Aya Soliman]

Hello ,

I have implemented TMR using th_fork() macro found in OpenPiton. I have instantiated 4 cores ,3 that implemnt the same MxM benchmark  that perform matrix multiplication then store it in different shared memory location . and the fourth acts as a majority voter that access these three different memory locations .

the weird observation here that race condition happened only when the majority voter tries to read the THIRD matrix output . which is extremely weird given that the same code is used in the three cores .. I would have expected that the first and the second matrix output too will suffer from race conditions ..

does it have ny relation that the configuration of the tiles is x_tiles=4 ,y_tiles=1 ,

so maybe data goes from the third and fourth core faster as they are close if they are organized in a row .. 

I don't have a good interpretation of the reason of this .. may i ask if you have an idea what might be the reason ?

Feel free to ask any details if you need .

thanks,

Aya

[Jonathan Balkind]

You shouldn't rely on any specific race condition behaviour as it is purely microarchitectural and results in uncertainty like this. If you want to guarantee ordering then you need to use fences, atomics/locks, etc. I would suggest you change your code to have some kind of locks/tokens/fencing to avoid the potential for this kind of thing occurring.

--
You received this message because you are subscribed to the Google Groups "OpenPiton Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpiton+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openpiton/27c5ddfb-b477-4ce3-922e-5c03a998f0efn%40googlegroups.com.