Cygwin multithreading performance

[Mark Geisert]

Corinna Vinschen wrote:
> On Dec  8 22:10, Mark Geisert wrote:
>> I probably need to modify my stats gathering program to display the total
>> time spent waiting to make it more clear how things add up for each mutex
>> across the whole testcase.  Again, these stats are not timing how long locks
>> are being held, but rather how long it takes just to acquire the lock.
>
> But acquiring a lock includes the time it actually has to wait for
> another thread holding the lock so you're measuring *also* the time
> locks are hold, just by another thread.  locking and unlocking a
> pthread_mutex in Cygwin might be slower than using a critical section,
> but it's not *that* slow.
>
> The underlying point is, mutexes are not used as an end in itself.  They
> guard a shared resource.  What we ultimately need to know here is
>
> 1. What resource is it the pthread_mutexes are guarding?
>
> 2. Why does accessing the resource take so long that threads have to wait
>     so long?

That sanity check was much appreciated.  I worked a bit longer on this then set 
it aside to wait for further inspiration while doing other work.  No such 
inspiration was forthcoming :) so I'll note what I found and close this off.

Bottom line, for the OP's original testcase having git do a repack of a locally 
cloned Cygwin source tree, on my test system the 4 parallel threads were 
spending no more than 6% of their time waiting for locks.  That includes the 
time those locks were held by some other thread.  So this line of investigation 
doesn't seem to answer the questions posed by the OP (i.e., why don't we see 
~100% CPU utilization during a presumably CPU-bound operation, and why does 
utilization seem so much lower with Cygwin git vs MinGW git).  I could 
speculate, but I won't.

I'm now looking into modifying the Cygwin profiling code to support the 
profiling of multi-threaded applications.  I'll post anew when I've got 
something to report.
Thanks & Cheers,

..mark