public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
From: Tristan Savatier <tristan@mpegtv.com>
To: "'pthreads-win32@sources.redhat.com'"
	<pthreads-win32@sources.redhat.com>
Subject: Mutex implementation questions
Date: Mon, 02 Oct 2000 15:01:00 -0000	[thread overview]
Message-ID: <39D907CE.29E2E536@mpegtv.com> (raw)
In-Reply-To: <430F887D415DD1118C2700805F31ECF1037F1388@SOTA0005>

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-02 15:01 UTC|newest]

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

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=39D907CE.29E2E536@mpegtv.com \
    --to=tristan@mpegtv.com \
    --cc=pthreads-win32@sources.redhat.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).