Mail Archives: cygwin/2001/06/25/22:46:10
Robert Collins wrote:
> >
> > My (heavily threaded) application runs approximately 100x
> > slower than under linux and proceeds to the point where the
> > program thrashes because it is calling pthreads functions
> > faster than the pthreads implementation can deliver (we're
> > talking _mutex_lock/unlock and _cond_wait/signal here).
>
> Condition variables we can't do much about here, other than trying to
> get down to the metal and rewrite em without OS support. I'm not keen to
> try that, for what I hope are obvious reasons.
True.
> > I realize very well that in a development scenario functionality
> > should come first and performance second. However, one of our
> > developers is insisting on writing his own pthreads implementation
> > for the application.
> > As a programmer, I hate to see dual pathing based on platform in the
> > code; hence this prod (er post).
>
> Please, get your colleague to improve the cygwin pthreads code. That
> will let him get his hands dirty, solve his problem, and prevent wastage
> :}.
Yes, I *am* trying to get the old coot ;-) to see the light...
sorta like draggin' a mule to water.
> > I also know that Rob is fully aware of the performance problem and
> > has ideas he wishes to implement, when he can spare some moments of
> > his valuable time. However, as of 1.3, our application doesn't run on
> > Win32 without kluging the threads implementation (by using a pthreads
> > implementation from ftp://sources.redhat.com/pub/pthreads-win32).
> > I am anxious to see pthreads `right' on Cygwin.
>
> I cannot read that implementation unfortunately - cygwin1.dll
> contributes require copyright assignment. However if someone is
> willing/able to give me relatively details english differences between
> their mature implementation and the cygwin1.dll one, I'm more than happy
> to recode what cygwin's got.
Holy batsh*t Batman!! I am a contractor to the government and am used
to unreasonable limitations, but, but, ... I had no idea. Does this mean
you can't look at the linux libc-pthreads implementation either ?!?
This reminds me of the dvd hack lawsuit a few months back... the defense
had a cs professor that showed to the court different algorithms of the
encryption method, in plain English, in pseudo-language, in C, etc, even
had it printed on t-shirts. The judge was intrigued but unsympathetic.
I also recall that we had to change *our* license to a gpl-type
(we chose QPL) to distribute our application with Cygwin...
> > I am willing to act as guinea pig or to contribute code myself. Alas,
> > I am a procedural programmer and not an OOPer; although I understand
> > the concept of classes, objects and methods, some of the syntax and
> > methodolgy eludes me. However, ignorance has never stopped me from
> > jumping in and getting wet before. I learned a long time ago that
> > when you jump into water where you don't know how deep it is, you don't
> > jump in head first, and not feet first, but butt first (the reader is
> > free to deduce any insights this analogy provides, if any ;-)
>
> I don't OOP that well either :]. Give me asm and I'm happy :/.
Wrote my first assembler in '75 and haven't stopped since :-P
> The first step greg is to use Critical Sections instead of mutex's for
> all non-process shared mutex's.
>
> howto do that? Read up on win32 mutex's and win32 critical sections.
> Then add a if (pshared) else clause to all the mutex member functions.
Thanks for the pointers (I already know all this, of course ;-)
Have the ..CriticalSection doc sitting right here beside me...
Later,
Greg
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -