From: mathieu.desnoyers@efficios.com (Mathieu Desnoyers)
Subject: [lttng-dev] [RFC] Feedback on 2 development branches: wfstack and lfstack
Date: Mon, 15 Oct 2012 09:28:07 -0400 [thread overview]
Message-ID: <20121015132807.GA3691@Krystal> (raw)
In-Reply-To: <507B7C41.60208@cn.fujitsu.com>
* Lai Jiangshan (laijs at cn.fujitsu.com) wrote:
> On 10/14/2012 02:12 AM, Mathieu Desnoyers wrote:
> > Hi!
> >
> > I started modifying the stack APIs to reflect the changes we did for
> > wfcqueue, and also add pop_all() and iterators.
> >
> > The volatile dev branches are available at:
> >
> > http://git.dorsal.polymtl.ca/~compudj?p=userspace-rcu;a=shortlog;h=refs/heads/urcu/lfstack
>
> I don't see the value of introducing struct cds_lfs_head.
> It can force the users to use for_each() for the return value of pop_all().
> Is it its purpose?
No exactly. The purpose of struct cds_lfs_head is to ensure that nobody
will attempt to use the for_each() iterators on struct cds_lfs_node
returned by __cds_lfs_pop(). I'm using typing to enforce usage
restrictions.
>
> thr_dequeuer() of a8edcc02a25328647f91b4bbe8207e8cdfd317d3 is too complicated.
> ( I don't see the value of @counter)
>
> do {
> ...
> if (test_pop) {
> test_lfs_pop;
> }
> if (test_pop_all) {
> test_lfs_pop_all;
> }
I will refactor the duplicated code into functions.
The reason why I use a mask on a counter to select pop or pop all is to
ensure that we do the "loop_sleep(rduration)" delay equally for both pop
and pop_all. Moreover, it will be easier to change the rate of pop vs
pop_all in the future, using a randomization function rather than 50-50
chances.
The update for both lfs and wfs will be pushed shortly,
Thanks!
Mathieu
> ...
> } while();
>
>
>
>
>
> > or
> > git://git.dorsal.polymtl.ca/~compudj/userspace-rcu
> > branch: urcu/lfstack
> >
> > http://git.dorsal.polymtl.ca/~compudj?p=userspace-rcu;a=shortlog;h=refs/heads/urcu/wfstack
> > or
> > git://git.dorsal.polymtl.ca/~compudj/userspace-rcu
> > branch: urcu/wfstack
> >
> > Sorry for not sending patches, I'm a bit time-constrained this weekend.
> > I am sending these links right away for review, because I think it might
> > be good to pull these commits into the master branch before we proceed
> > to other changes. And I want to minimize the amount of duplicated effort
> > between Lai and myself.
> >
> > One of my next step will be to document the wfstack and lfstack APIs
> > more thoroughly (similarly to what we did for wfcqueue).
> >
> > Then, my following step will be to see if I can implement a lfcqueue
> > API, derived from wfcqueue, but with lock-free enqueue semantic (a mix
> > of wfcqueue and rculfqueue).
> >
> > Feedback is welcome!
> >
> > Thanks,
> >
> > Mathieu
> >
> >
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
prev parent reply other threads:[~2012-10-15 13:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-13 18:12 Mathieu Desnoyers
2012-10-15 3:00 ` Lai Jiangshan
2012-10-15 13:28 ` Mathieu Desnoyers [this message]
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=20121015132807.GA3691@Krystal \
--to=mathieu.desnoyers@efficios.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