Efficient time checking using the interval timer

[sje]

There are three time checks in a search, all for different limits:

1) At each node

2) Before the start of searching for the next candidate move

3) Before the start of the next iteration

Also, time limits can change during a search under certain circumstances.

I'm not interesting in calling setitimer() more than once per program invocation. And as I mentioned before, the tick counter is used for more than just search time limits:

1) Instances of the progress meter class

2) Tracking time used per each candidate move search for move re-ordering at the root

[sje]

Why? In most OS systems, once you set a handler for SIGNIT it remains for all time.

Symbolic assumes that upon return from the signal handler that the handler may again be invoked without having to re-register the handler with a call to signal(). This should work on any Unix from the past twenty years, but it would not work with the very early Unixes which required an explicit re-registration.

Symbolic tries not to make any assumptions about what might happen if the same signal occurs while its handler is still processing a previous occurrence. It does this by limiting the handler to do only one increment, one addition, and two assignments, something which will run so fast that it likely will never see an interrupt. And even if it did, nothing critical will be lost and the program won't hang.

Code: Select all

static void HandleSIGALRM(int value)
{
  DIPtr->TickCount++;
  DIPtr->UsecCount += TickTimeLen;
}

The handlers for SIGHUP, SIGINT, SIGSTOP, and SIGTERM are similar.

Running the interval timer at 100 Hz has shown zero measurable overhead, even on hardware from a decade ago.

[flok]

Hi,

Totally different platform but what I do in my java program is:

- start a thread wait does a Thread.sleep(thinkTime * 1000 - 5) which effectively sleeps "thinkTime" seconds minus 5 milliseconds

- when the sleep finishes, it sets an atomic boolean to true. I measured(!) that reading an atomic boolean hardly takes any time. only the first read after it is set is huge (because of cache invalidation)

Then my search-loop has for each node a check for that atomic boolean and simple returns null if it is set.

I don't think a "volatile" is the same as an atomic*-variable in java as a volatile can never be cached while an atomic*-variable can.

[sje]

Volatile means that the value must be reloaded from memory each time it is referenced, usually because its value can be changed by another thread executing concurrently.

Atomic means that the value can be completely changed by a thread without interference from another thread. I believe that all normal writes which can be done with a single memory access are guaranteed to be atomic. An exception would be a 64 bit write on a 32 bit machine.

In Mac OS/X there is a family of routines which perform atomic operations which can involve multiple variables and list operations. These include an internal mutex like a spin lock which provides the needed barrier to support exclusive access by the caller.