public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
From: "Bossom, John" <John.Bossom@Cognos.COM>
To: 'Tristan Savatier' <tristan@mpegtv.com>
Cc: "'pthreads-win32@sources.redhat.com'"
	<pthreads-win32@sources.redhat.com>
Subject: RE: Mutex implementation questions
Date: Tue, 03 Oct 2000 04:38:00 -0000	[thread overview]
Message-ID: <430F887D415DD1118C2700805F31ECF1037F1394@SOTA0005> (raw)

You are correct... critical sections are almost 100 times faster than
actual kernel based mutexes... however...

1) Mutexes (i.e. kernel based) are useful in that you can support a
   lock-with-timeout... a feature that is being pondered as an upgrade
   to pthreads.
2) Mutexes can use WaitForMultipleObjects (sp?) which allows you to simulate
   a cancel by waiting on a cancel event as well as the mutex.
3) TryEnterCriticalSection is not supported on Win95/98 (originally it was
   completely left out... then they added a stub that simply returns
   "function not supported", thus there is no way to implement
   pthread_mutex_trylock; hence if you need "trylock" you need to use a
   real mutex.
3) By eliminating the DllMain, whose purpose was to perform
   behind the scenes cleanup of the "self" structure as well as calling
   all the destructors for thread-specific data keys, what alternate
   approach did you take for doing this thread-based cleanup?
   (i.e. I leveraged the fact that DllMain is called each time a thread
         is started/finished to perform thread based initialization/cleanup)

I hope this clears up some of your questions.

Cheers,

John.

-----Original Message-----
From: Tristan Savatier [ mailto:tristan@mpegtv.com ]
Sent: Monday, October 02, 2000 6:10 PM
To: 'pthreads-win32@sources.redhat.com'
Subject: Mutex implementation questions


I noticed that if _pthread_try_enter_critical_section has been set
to a non-NULL value by DllMain, Mutexes are implemented using
critical sections (InitializeCriticalSection) instead of 
CreateMutex, regardless of the value of the implemetation-specific
forcecs
mutex attribute.

According to "Win32 programming", critical sections are light weight
compared to mutexes, they are not managed by the kernel, and they
are much faster than mutexes.  So why no use critical sections
all the time to implement pthread mutexes ?

Are there cases where critical sections are not available or
wouldn't work well ?

The DllMain seems to do some tests to check if InitializeCriticalSection
exists and works.  What are the cases where critical sections
would not be available ?

Also, I have a suggestion:

It might be a good idea to add a compile flag to
allow the use of pthread-win32 with static linking
(i.e. to make just a pthread.lib, no dll).

In this case, a compilation flag should be added to exclude the DllMain
routine. Also, the code that sets _pthread_try_enter_critical_section
should be moved from DllMain to _pthread_processInitialize.  The
_pthread_processInitialize should be made global and it should
be called by the application to initialize pthread.

We had to change the pthread code to do all that in our
WinCE application.

-t

             reply	other threads:[~2000-10-03  4:38 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-10-03  4:38 Bossom, John [this message]
2000-10-05 19:55 ` Tristan Savatier
2000-10-08 21:58   ` Ross Johnson
  -- strict thread matches above, loose matches on Subject: below --
2000-10-11  8:37 Bossom, John
2000-10-02 15:04 Scott McCaskill
2000-10-02 15:59 ` Tristan Savatier
2000-10-02 23:24   ` Ross Johnson
2000-09-28 10:53 Memory leak in pthread_setcanceltype()? Bossom, John
2000-10-02 15:01 ` Mutex implementation questions Tristan Savatier
2000-10-02 23:36   ` Ross Johnson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=430F887D415DD1118C2700805F31ECF1037F1394@SOTA0005 \
    --to=john.bossom@cognos.com \
    --cc=pthreads-win32@sources.redhat.com \
    --cc=tristan@mpegtv.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).