{"comment":{"url":"https://api.github.com/repos/mcostalba/Stockfish/comments/14115648","html_url":"https://github.com/mcostalba/Stockfish/commit/edac860627b6706e1c0722812c72731dc02d463d#commitcomment-14115648","id":14115648,"user":{"login":"zamar","id":2694706,"avatar_url":"https://avatars.githubusercontent.com/u/2694706?v=3","gravatar_id":"","url":"https://api.github.com/users/zamar","html_url":"https://github.com/zamar","followers_url":"https://api.github.com/users/zamar/followers","following_url":"https://api.github.com/users/zamar/following{/other_user}","gists_url":"https://api.github.com/users/zamar/gists{/gist_id}","starred_url":"https://api.github.com/users/zamar/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/zamar/subscriptions","organizations_url":"https://api.github.com/users/zamar/orgs","repos_url":"https://api.github.com/users/zamar/repos","events_url":"https://api.github.com/users/zamar/events{/privacy}","received_events_url":"https://api.github.com/users/zamar/received_events","type":"User","site_admin":false},"position":null,"line":null,"path":"","commit_id":"edac860627b6706e1c0722812c72731dc02d463d","created_at":"2015-11-01T18:29:27Z","updated_at":"2015-11-01T18:29:27Z","body":"@mcostalba: Sure, but for TT access we don't have a choice... If we had I'd\nchange it straight away.\n\nOn Sun, Nov 1, 2015 at 4:33 PM, Marco Costalba <notifications@github.com>\nwrote:\n\n> It is completely undefined as is a TT access... Nevertheless it works.\n>\n> Even if in the counter ends up to be filled with complete random garbage,\n> the worst it can happen is to have a spurious check time call, and counter\n> is reset to zero at the next tick.\n>\n> I will try to write something with atomics, hoping (and testing) it does\n> not regress, but in this case it is really overkill and IMO not needed.\n>\n>\n>\n>\n> Ogn Sunday, November 1, 2015, Joona Kiiski <notifications@github.com>\n> wrote:\n>\n> > @mcostalba:\n> >\n> > - Until a month ago we used volatile boolean flags to pass some flags\n> > between threads. For splitpoint shared variables we always used lock\n> > protection to guarantee the expected behaviour.\n> >\n> > - What we are trying to do here is completely unorthodox... Sure it works\n> > well with a spinlock or mutex, but without them the behaviour is\n> completely\n> > unspecified.\n> >\n> > On Sun, Nov 1, 2015 at 10:01 AM, Marco Costalba <\n> notifications@github.com\n> > <javascript:_e(%7B%7D,'cvml','notifications@github.com');>>\n> > wrote:\n> >\n> > > @zamar <https://github.com/zamar> timeCounter is (mostly) a local\n> thread\n> > > object, it is incremented just by one thread and only very occasionally\n> > it\n> > > is reset to zero by another thread. If we set it atomic, we force a\n> sync\n> > > after every increment, completely giving up the advantage of a local\n> > > counter. Moreover until one month ago, we always used shared variable\n> in\n> > > this way and it worked well (as it works well in C where there is no\n> > > atomic). Said that, we *could* use\n> > >\n> > > std::atomic_fetch_add(&timeCounter, 1, std::memory_order_relaxed)\n> > >\n> > > instead of\n> > >\n> > > ++timeCounter\n> > >\n> > > But it seems to me an (unnecessary) overkill.\n> > >\n> > > —\n> > > Reply to this email directly or view it on GitHub\n> > > <\n> >\n> https://github.com/mcostalba/Stockfish/commit/edac860627b6706e1c0722812c72731dc02d463d#commitcomment-14113328\n> > >\n> > > .\n> > >\n> >\n> > —\n> > Reply to this email directly or view it on GitHub\n> > <\n> https://github.com/mcostalba/Stockfish/commit/edac860627b6706e1c0722812c72731dc02d463d#commitcomment-14114758\n> >\n>\n> > .\n> >\n>\n> —\n> Reply to this email directly or view it on GitHub\n> <https://github.com/mcostalba/Stockfish/commit/edac860627b6706e1c0722812c72731dc02d463d#commitcomment-14115017>\n> .\n>\n"}}