This is the mail archive of the mailing list for the pthreas-win32 project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]


Hello Ross, John, and pthreads-win32:

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.

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.

craig vanderborgh
voxware incorporated

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]