From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Vijay <thelonejoker@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Workqueue behaviour - Synchronization within submitted work.
Date: Sun, 24 Mar 2013 17:02:34 +0100 [thread overview]
Message-ID: <20130324170234.0eeb1fe9@stein> (raw)
In-Reply-To: <CAEtk5ge3MBn5759EfUVdNRmb2g=kvtbe7u+xkZXy5E0KoynoJw@mail.gmail.com>
On Mar 20 Vijay wrote:
> In the new workqueue architecture, I have a question regarding
> synchronization between different "work" submitted to the same
> workqueue. For example:
>
> * I submit two "works" A and B to a common driver specific workqueue (W).
> * Each A and B, meddle with a certain shared data SD.
> * Am I guaranteed serialized execution of A and B, or should I play
> safe and use a semaphore (acquire/release) with A and B ?
The works A and B may be (and more or less likely will be) executed in
parallel --- except if you create the workqueue with parameters @flags |=
WQ_UNBOUND and @max_active = 1. alloc_ordered_workqueue() is a shorthand
for creation of such a workqueue.
Some more thoughts:
- If you go for an ordered workqueue and no other means of serialization
of accesses to your data, check carefully that these data are indeed
never accessed in other contexts besides the workers.
- For serialization in non-atomic context, a struct mutex is usually
preferred over a struct semaphore. The foremost advantage of mutexes
over counting semaphores is that code using the former can be debugged
much easier.
--
Stefan Richter
-=====-===-= --== ==---
http://arcgraph.de/sr/
next prev parent reply other threads:[~2013-03-24 16:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-20 18:45 Workqueue behaviour - Synchronization within submitted work Vijay
2013-03-24 16:02 ` Stefan Richter [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-03-21 0:56 Vijay
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=20130324170234.0eeb1fe9@stein \
--to=stefanr@s5r6.in-berlin.de \
--cc=linux-kernel@vger.kernel.org \
--cc=thelonejoker@gmail.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