Test step functions may not function as expected in a multithreaded environment about mbedtls HOT 2 OPEN

Out of curiosity, why is reporting the test step more difficult than reporting the file/line location?

from mbedtls.

Reporting the line / location is guarded by the test result state - we take the lock, then set the test name, line and file (and the two extra lines if necessary), and then unlock. Should a second thread come along at this point, they would bounce off as the test had already failed.

When setting the step (to an arbitary value) there is no such built in safeguard, one simply sets the step. If two threads are both attempting to set the step, then the order in which they set the step (one obviously overwriting the other) is completely undetermined. Even if we constrained the step value to a single test, and that test used threads we would hit this, so I'm really not entirely sure, as I said how best to fix it.

In the case of increment step, if its basically being used as a counter, then it will function as that, but there is still uncertainty about the order in which increments happen, however if that is not something you are bothered about then this is still useful in a multi-thread environment.

from mbedtls.