linux-kernel - Re: Workqueue behaviour - Synchronization within submitted work.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20130324170234.0eeb1fe9@stein>
Date:	Sun, 24 Mar 2013 17:02:34 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Vijay <thelonejoker@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Workqueue behaviour - Synchronization within submitted work.

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/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/