Hi,
The race condition in this case is not hardware problem (we do not need additional synchronization mechanism to protect pMutex->waiters at least on machines for which Harbour can be ported) but logical one.
OK. I was afraid , that accessing pMutex->waiters could cause garbage on some systems in some cases like, unaligned data, etc. If pMutex->waiters is atomic, I see no problem.
Just simply the returned value does not give any precise information which can be used in some algorithms which need strict number of waiters. For programmer it's only approximated number of waiters. Of course such information can also be usable but only if used algorithm does not need strict value. Please note that in fact it's not guarantied that you will create such two threads for each connection. This code can create more or less threads.
Yes, I know this. I just need a kind of statistics, or information about mutex queue to make process allocation more optimal. If information is not precise nothing wrong will happen, the query will be queued and processed later by existing thread.
In this case you will have better approximation if you also use the size of message queue and calculate the difference between pMutex->waiters and hb_arrayLen( pMutex->events ) (accessing pMutex->events should be covered by lock) and proposed by you HB_MUTEXQUEUEINFO() gives such
Thanks for this valuable idea. I'll use it in my code. Regards, Mindaugas _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
