Kacper Michajlow wrote:
2015-12-05 23:40 GMT+01:00 Mark Geisert <m...@maxrnd.com>:
It looks like we're going to have to compare actual pthread_mutex_lock()
implementations. Inspecting source is nice but I don't want to be chasing a
mirage so I really hope there's a pthread_mutex_lock() function inside the
MinGW git you are running. gdb could easily answer that question. Could
you please do an 'info func pthread_mutex_lock' after starting MinGW git
under MinGW gdb with a breakpoint at main() (so libraries are loaded).
[...]
Hmm, thinking about it mingw doesn't have pthread implementation or
any wrapper for it. If someone needs pthread they would probably go
for pthreads-w32 implementation.
I started to wonder because I don't recall git would need pthreads to
compile on Windows. And indeed they have a wrapper for Windows API...
https://github.com/git/git/blob/master/compat/win32/pthread.h
https://github.com/git/git/blob/master/compat/win32/pthread.c
OK, so git has its own pthread_mutex_lock/unlock ops which map to very
light-weight critical section operations.
Though it is not really a matter that "native" git build is fast and
all, but that Cygwin's one really struggles if it comes to MT workload.
In the worst cases I see using your testcase, about half the time the
busiest locks are processed within 1 usec but there's a spectrum of
longer latencies for the other half of the time. I don't know (yet) if
that can be improved in Cygwin's more general implementation but at
least the matter has now been brought to our attention :).
And this not only issue with git unfortunately. Download speeds are
also limited on Cygwin. I know POSIX compatibility layers comes with a
price but I would love to see improvements in those areas.
Cygwin:
Receiving objects: 100% (230458/230458), 78.41 MiB | 1.53 MiB/s, done.
"native" git:
Receiving objects: 100% (230458/230458), 78.41 MiB | 18.54 MiB/s, done.
You're asserting this additional testcase has the same cause. What is
telling you that? And FTR what is the git command you are issuing? I
can then do the lock latency analysis on this new testcase if warranted.
Thanks,
..mark
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
