transposition and multithreading question

[mcostalba]

I have then looked at senpai code and it correctly read the data from the transposition and copy them in the search variables

"Correct" is a difficult concept in SMP programming.

If with "correct" you mean "race free" than no, Senpai code is no more correct than SF: both are racy.

The only difference is the race window, copying directly makes the race window very small, but also in SF, as you can see, we deference tte pointer only few cycles later that we acquired it, so the race windw in SF is max 2-3 time wider than in Senpai, no more.

It means that if in Senpai we have a race every, say, one billion reads, in SF we can have about three every one billion reads: really nothing that we have to worry about. The read from TT usually is order of magnitudes more inaccurate that this (because is the result of a finite depth search, and so a deeper search could yield a completely different result).

[elcabesa]

"Correct" is a difficult concept in SMP programming.

If with "correct" you mean "race free" than no, Senpai code is no more correct than SF: both are racy.

The only difference is the race window, copying directly makes the race window very small, but also in SF, as you can see, we deference tte pointer only few cycles later that we acquired it, so the race windw in SF is max 2-3 time wider than in Senpai, no more.

It means that if in Senpai we have a race every, say, one billion reads, in SF we can have about three every one billion reads: really nothing that we have to worry about. The read from TT usually is order of magnitudes more inaccurate that this (because is the result of a finite depth search, and so a deeper search could yield a completely different result).

you are absolute right, if senpai used lock inside transposition table function it would probably be "race free".
I understood your explanation.