public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
From: "Evstiounin, Mikhail" <Mikhail.Evstiounin@ca.com>
To: "Stephen Croall" <scroall@tibco.com>,
		<pthreads-win32@sources.redhat.com>
Subject: RE: Good Algorithm for "Multiple Readers"/"Multiple Writers"
Date: Thu, 08 Dec 2005 15:00:00 -0000	[thread overview]
Message-ID: <163D3F27E93137439CEB0BB9382257E7187681@USILMS12.ca.com> (raw)

You can get more parallelism in terms of processing, but you are not
going to get more parallelism in terms of getting access to the
protected resource. In the last sense there is no difference between
single and multiple writers and advice given by Rustam is correct. Just
call pthread_rwlock_timedwrlock in every writer. Model single writer
multiple reader means that at any given moment you can have multiple
readers having access to a resource and only one writer. That does not
mean that you have to have one writer in your program. 


-----Original Message-----
From: Stephen Croall [mailto:scroall@tibco.com] 
Sent: Thursday, December 08, 2005 9:08 AM
To: Evstiounin, Mikhail; pthreads-win32@sources.redhat.com
Subject: RE: Good Algorithm for "Multiple Readers"/"Multiple Writers"

 
We already use read/write locks in places but for greater parallelism
multiple reader and multiple writer locks would be better.

The current read/write lock implementation in POSIX doesn't support
multiple writers.  Only one writer thread can process at a time - as I
would expect.

I'm after a good model for writing a "many readers"/"many writers" lock
implementation, which is portable from Windows to UNIX.

Steve.

-----Original Message-----
From: Evstiounin, Mikhail [mailto:Mikhail.Evstiounin@ca.com] 
Sent: 08 December 2005 14:02
To: Stephen Croall; pthreads-win32@sources.redhat.com
Subject: RE: Good Algorithm for "Multiple Readers"/"Multiple Writers"

I did not quite get it. The difference between reader and writer is that
reader locks out writer and lets other readers continue without waiting
while writer acquire an exclusive lock. Multiple writers will have
serialized access to a resource in any case. So, there no difference
from this point of view between "one writer -- many readers" and "many
writers -- many readers". So, if you are going to use FIFO (or you don't
care -- I made an assumption that all requests for resource locking is
based on FIFO which is not true, generally speaking) in terms of how to
process request queue then posix approach is enough.

-----Original Message-----
From: pthreads-win32-owner@sourceware.org
[mailto:pthreads-win32-owner@sourceware.org] On Behalf Of Stephen Croall
Sent: Thursday, December 08, 2005 4:57 AM
To: pthreads-win32@sources.redhat.com
Subject: RE: Good Algorithm for "Multiple Readers"/"Multiple Writers"


Thanks, but the POSIX read/write interface supports a single writer vs.
multiple readers.  I'm after multiple writers & readers i.e. multiple
threads can perform writing but readers must wait and vice versa.

Steve.

-----Original Message-----
From: Rustam T. Usmanov [mailto:rustam@unilib.neva.ru] 
Sent: 08 December 2005 09:54
To: Stephen Croall
Subject: Re: Good Algorithm for "Multiple Readers"/"Multiple Writers"

On Thu, 8 Dec 2005, Stephen Croall wrote:

> Is anyone aware of whether POSIX implements this type of lock?

pthread_rwlock ? See
http://www.opengroup.org/onlinepubs/009695399/functions/pthread_rwlock_i
nit.html

--
Rustam Usmanov, systems engineer
Institute of Consortia Library Information Systems,
St.Petersburg State Polytechnic University
Address:  29, Politekhnitcheskaya str., St.Petersburg, 195251, Russia
Tel/fax: +7 812 552 7654        <URL:http://www.unilib.neva.ru/olsc/>


             reply	other threads:[~2005-12-08 15:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-08 15:00 Evstiounin, Mikhail [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-12-08 16:35 Stephen Croall
2005-12-08 15:47 Evstiounin, Mikhail
2005-12-08 15:16 Stephen Croall
2005-12-08 15:11 Stephen Croall
2005-12-08 15:09 Stephen Croall
2005-12-08 15:06 Evstiounin, Mikhail
2005-12-08 15:06 Stephen Croall
2005-12-08 15:02 Evstiounin, Mikhail
2005-12-08 15:01 Stephen Croall
2005-12-08 14:49 Stephen Croall
2005-12-08 14:09 Stephen Croall
2005-12-08 14:53 ` Robert Kindred
2005-12-08 14:02 Evstiounin, Mikhail
2005-12-08  9:57 Stephen Croall
2005-12-08  9:09 Stephen Croall
2005-12-08 14:46 ` Robert Kindred

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=163D3F27E93137439CEB0BB9382257E7187681@USILMS12.ca.com \
    --to=mikhail.evstiounin@ca.com \
    --cc=pthreads-win32@sources.redhat.com \
    --cc=scroall@tibco.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).