kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: j.neuschaefer@gmx.net (Jonathan Neuschäfer)
To: kernelnewbies@lists.kernelnewbies.org
Subject: How to implement a driver's read and write operations with synchronization properly
Date: Tue, 29 Jul 2014 10:36:38 +0200	[thread overview]
Message-ID: <20140729083638.GG3694@debian> (raw)
In-Reply-To: <CAPmaJ=DZ_MbRhxYrbuh5s6nRcPYkhcCcMWwv=8sEkfvjHUoZfA@mail.gmail.com>

On Tue, Jul 29, 2014 at 03:03:55PM +0700, Anh Le wrote:
> Hi everyone,
> I'm trying to write a misc char driver with read and write operations,
> and I choose reader writer lock for synchronization between them.
> Suppose that when writing 2000 bytes, the write operation is called
> twice, each time writing only 1000 bytes. There are 2 ways to
> implement synchronization as below:

Which "write operation" is called twice in your scenario?

> 1. Acquire and release lock everytime the write operation is called.
> Same with read operation.
> 2. Acquire the lock when the write operation is called for the first
> time, and release when the whole write procedure is completed. In this
> case, the lock is acquired before transfering the 1st byte, and
> released after transfering the 2000th byte. Same with read operation.

If a userspace program writes 1000 bytes at first, how can you know that
it wants to perform another write later on?

> As how I see it, both of these approaches have problems. The first one
> release the lock in between the write operations, so a reader can get
> in while the writer has only finished a portion of its work.

If a userspace program wants to write a chunk of data atomically, it
should use just one call to write(2). (On Linux, one can save some
copying by using writev(2), which writes data from multiple buffers in
one atomic step.)

> With the
> second approach, I have no way to tell that the write procedure ends
> with the 2000th byte. What if there are more?

Again, where does this write procedure run?


Greetings,
Jonathan Neusch?fer

> Could anyone tell me the proper way to deal with this situation?
> Thanks in advance.
> 
> -- 
> Le Quoc Anh

  reply	other threads:[~2014-07-29  8:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-29  8:03 How to implement a driver's read and write operations with synchronization properly Anh Le
2014-07-29  8:36 ` Jonathan Neuschäfer [this message]
2014-07-29 11:59 ` Pranay Srivastava
  -- strict thread matches above, loose matches on Subject: below --
2014-07-29 12:15 Anh Le
2014-07-29 12:33 ` Pranay Srivastava
2014-07-29 12:47 ` Jonathan Neuschäfer
2014-07-29 13:59 Anh Le
2014-07-29 14:24 ` Valdis.Kletnieks at vt.edu
2014-07-29 18:49   ` Jonathan Neuschäfer

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=20140729083638.GG3694@debian \
    --to=j.neuschaefer@gmx.net \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /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 NNTP newsgroup(s).