Atomic thread count update

[martinjos]

The current master version of ReluVal can sometimes create more than MAX_THREAD threads. This can be seen by applying only the first commit in this pull request (track max simultaneous threads). Max simultaneous thread counts greater than 56 are sometimes reported.

This happens for two reasons:

1. It doesn't atomically check and update count - instead, it acquires a lock, checks count (effectively entering a "guarded block"), releases the lock, acquires it again, and then increases count. While the lock is released, any number of other active threads can also check count and enter the guarded block, because they have no way of knowing that another thread has already done so (or, indeed, how many other threads have already passed the check but not yet updated count). This is fixed by releasing the lock only after updating count.
2. The guard itself is count <= MAX_THREAD when it should be count+2 <= MAX_THREAD, accounting for the two extra threads that will be created.

Both issues are fixed by this pull request. In addition, the max simultaneous thread count is now reported. This doesn't seem to affect timings, so I've left it in.

An added benefit of this pull request is that it reduces the amount of locking, potentially reducing contention and making the program more efficient overall.