From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7820 invoked by alias); 28 Feb 2003 18:59:38 -0000 Mailing-List: contact pthreads-win32-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sources.redhat.com Received: (qmail 7813 invoked from network); 28 Feb 2003 18:59:37 -0000 Received: from unknown (HELO calypsoo.voxware.com) (63.167.41.125) by 172.16.49.205 with SMTP; 28 Feb 2003 18:59:37 -0000 Received: from zetar (12-253-95-100.client.attbi.com [12.253.95.100]) by calypsoo.voxware.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F5WAH6J5; Fri, 28 Feb 2003 13:59:36 -0500 Subject: WINCE: problems w/CRITICAL_SECTION From: "Craig A. Vanderborgh" To: pthreads-win32@sources.redhat.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 28 Feb 2003 18:59:00 -0000 Message-Id: <1046458987.32515.92.camel@zetar> Mime-Version: 1.0 X-SW-Source: 2003/txt/msg00032.txt.bz2 Hello Ross, John, and pthreads-win32: Background: We have a very big and extremely complex pthreads application that is mature and has been thoroughly tested. Basically, it is a continuous speech recognizer that operates in real time. We have had it running on wince for a long while under what I call "craig-threads" - it's a pthreads subset that lacks condition variable support. I became interested in using pthreads-win32 to get complete support for condition variables and a few other things. Our application does not work correctly on pthreads-win32 though, and for an interesting reason. It appears that the M$ CriticalSection stuff isn't working correctly on WINCE, at least for our application. I did the following experiments: 1. Ran application under pthreads-win32. Result: unexpected hang "way down there" 2. Ran application under craig-threads w/CreateMutexW and associated stuff for pthread_mutex_*. Result: works 3. Ran application under craig-threads w/InitializeCriticalSection and associated stuff for pthread_mutex_*. Result: same exact behavior as 1. above. So it would seem that the M$ CRITICAL_SECTION stuff is implicated. I have read that we will be paying a performance penalty if we have to use a M$ mutex instead of CRITICAL_SECTION. Is this true, and how bad is it? Our application uses synchronization objects with a very high bandwidth, btw. Do you think I should modify pthreads-win32 so that one could optionally use mutex/WaitForSingleObject in place of CRITICAL_SECTION? Is there some way I might be able to debug the CRITICAL_SECTION version(s) of our application? Please advise. regards, craig vanderborgh voxware incorporated