public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
From: Eli Ofenstein <elio@clearcommerce.com>
To: "'ssundaragopalan@hss.hns.com'" <ssundaragopalan@hss.hns.com>,
	 pthreads-win32@sources.redhat.com
Subject: RE: pthread_init_mutex problem
Date: Sat, 04 May 2002 10:01:00 -0000	[thread overview]
Message-ID: <0530398ED6DBD211AC9200902745F005082DFECE@goldberg.internal.clearcommerce.com> (raw)


Hi

In general, sync primitives as data structures aren't really meant to be
transient.  A high cost at init time is not uncommon.  In terms of
protecting data that is transient, perhaps a scheme for reusing the
data structures would be in order.  Something like maintaining a linklist,
or, even better, per-thread linklists on a TLS key.  Of course, this assumes
near-identical produce and consume rates.

> -----Original Message-----
> From: ssundaragopalan@hss.hns.com [mailto:ssundaragopalan@hss.hns.com]
> Sent: Saturday, May 04, 2002 2:08 AM
> To: pthreads-win32@sources.redhat.com
> Subject: pthread_init_mutex problem
> 
> 
> 
> 
> hi all,
>         i am new to this mailing list. i am using pthreads 
> for windows and
> have the following problems.
> The function pthread_mutex_init is taking up CPU to a large 
> extent....In
> our program we have a lock for each data structure and this 
> data struture
> is initialized every time a new messsage is received. So under Load
> conditions the CPU utilization is reaching 100%.
> Can anyone suggest some ways to bring down this.
> 
> regds,
> srikanth
> 
> 
> 
> 
> 
> 
> This message is proprietary to Hughes Software Systems 
> Limited (HSS) and is
> intended solely for the use of the individual to whom it is 
> addressed.  It
> may contain privileged or confidential information and should not be
> circulated or used for any purpose other than for what it is 
> intended.  If
> you have received this message in error, please notify the originator
> immediately.  If you are not the intended recipient, you are 
> notified that
> you are strictly prohibited from using, copying, altering, or 
> disclosing
> the contents of this message.  HSS accepts no responsibility 
> for loss or
> damage arising from the use of the information transmitted by 
> this email
> including damage from virus.
> 
> 

             reply	other threads:[~2002-05-04 17:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-04 10:01 Eli Ofenstein [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-05-06  7:16 ssundaragopalan
2002-05-06 20:53 ` Phil Frisbie, Jr.
2002-05-04 10:42 5qduh001
2002-05-04  4:19 ssundaragopalan
2002-05-04  0:09 ssundaragopalan
2002-05-04 11:28 ` Phil Frisbie, Jr.

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=0530398ED6DBD211AC9200902745F005082DFECE@goldberg.internal.clearcommerce.com \
    --to=elio@clearcommerce.com \
    --cc=pthreads-win32@sources.redhat.com \
    --cc=ssundaragopalan@hss.hns.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).