I'm completely rewriting this thread because I did some testing and my problem changed completely. I have an (urgent (but don't worry about that)) assignment that requires the usage of threads and semaphores. Because of my design, I also need a chronometer. To help me train semaphore usage, I decided to make the chronometer thread-safe using semaphores too.
When I used a theoretically worse chronometer, the project worked OK most of the time. Now that I'm using a chronometer that is theoretically more correct, and that worked perfectly alone, the chronometer is behaving weirdly when used in the project.
I'll explain the code before posting it. I have the run() method, which runs forever in a while loop. Firstly, it acquires a lock to a semaphore. Then, it reads a boolean variable that determines which path it will take. If it's true, it will do some processing that doesn't block and will release the lock. If the variable is false, it will release the lock and will acquire the lock of another semaphore, which is used in the place of an Object.wait(). This variable is set by other methods only, never inside the run() method.
When I use my chronometer in my project, and I call the startCount() method, it will set the variable to start counting (true) and will release both locks. The run() method, which was blocked in either semaphore, will continue execution and read the variable. But then the variable magically became false again and the chronometer will wait another iteration. If I use successive calls to release the wait semaphore, the variable will still be false.
I even encapsulated the variable to a class, where methods must be used to read/write in it, and every method prints a stack trace. It's executing as expected. The value just magically changes back.
What's going on? I don't think I can post the code for the rest of my project, for it's about 1.600 lines long. I'll post the chronometer and the test harness I used for the individual tests. Remembering that this test harness will not reproduce the error.