Ethan Solomita wrote:
There have been several changes to the webrev for 5062435, and so I'm putting it out for a second review. The most important was my ass*u*mption that just because the CPU obeyed TSO rules, that the compiler couldn't screw it up. Unfortunately it's almost impossible to prevent a compiler from reordering stores without declaring everything volatile.
So I decided to accept the performance hit in new_cpu_mstate() and call membar_producer() which will generate either a membar #StoreStore, or an sfence.
membar #storestore is effectively a nop on all existing sparc processors because they only support TSO mode. So there's no performance penalty. Is there any chance that cpu_mstate_gen wraps around between two loads of cpu_mstate_gen in get_cpu_mstate(), making them return the same value ? Not very likely but is there anything that will prevent such a case ? Seongbae _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
