As noted in the source file threadTasks.cpp under the copy constructor instances, there is a to-do note referring to a potential bug in the system being created there.
While general copy constructing is safe, this instance may not always provide the exact result that is desired by the system. The problem here is that if another thread, or multiple threads are using an instance of the TSCounter and manipulating the value when the copy constructor is called, the value may not be 100% representative of what was expected for a result.
There are a few possible routes to explore in terms of "fixes" for the system, one of which is to implement a MutexLock() declaration on the counter's copy constructor to block direct access to it while the constructor is being used.
For the time being however, I'm going to leave it as it is presented and label this as an RC3 item for future reference.
As noted in the source file threadTasks.cpp under the copy constructor instances, there is a to-do note referring to a potential bug in the system being created there.
While general copy constructing is safe, this instance may not always provide the exact result that is desired by the system. The problem here is that if another thread, or multiple threads are using an instance of the TSCounter and manipulating the value when the copy constructor is called, the value may not be 100% representative of what was expected for a result.
There are a few possible routes to explore in terms of "fixes" for the system, one of which is to implement a MutexLock() declaration on the counter's copy constructor to block direct access to it while the constructor is being used.
For the time being however, I'm going to leave it as it is presented and label this as an RC3 item for future reference.