Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Message-ID: <3B37F19F.C9BCDA23@nc.rr.com>
Date: Mon, 25 Jun 2001 22:21:19 -0400
From: Greg Smith <gsmith AT nc DOT rr DOT com>
MIME-Version: 1.0
To: Cygwin General MailList <cygwin AT cygwin DOT com>
Subject: Re: pthreads works, sorta
References: <3B37D1A6 DOT 39A2685 AT nc DOT rr DOT com> <03c701c0fdd7$82ddbde0$0200a8c0 AT lifelesswks>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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/