From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Yubin Ruan <ablacktshirt@gmail.com>
Cc: perfbook@vger.kernel.org
Subject: Re: synchronization between two process without lock
Date: Fri, 4 Aug 2017 12:50:49 -0700 [thread overview]
Message-ID: <20170804195049.GF3730@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAJYFCiOE9MBj+t_biHVvzso6XZWvuYGH-xhxF3TKyKQVDqJRHw@mail.gmail.com>
On Fri, Aug 04, 2017 at 11:57:28PM +0800, Yubin Ruan wrote:
> 2017-08-04 22:52 GMT+08:00 Yubin Ruan <ablacktshirt@gmail.com>:
> > Hi,
> > I am sure the subject explain my intention. I got two processes trying
> > to modifying the same place. I want them to do it one after one, or,
> > if their operations interleave, I would like to let them know that the
> > content have been changed and polluted by the other so that the
> > content should be given up. That is, I would rather give up the data,
> > if polluted, than having a false one.
> >
> > I try to set a atomic ref counter, but it seems impossible to do that
> > without a lock to synchronize.
> >
> > Note that I don't want a strict synchronization: the situation is a
> > lot better. The data can be given up if that place has been polluted.
>
> Let's explain some of my reasoning: if process A use some flag to
> indicate that it has entered the critical region, then if it crash
> before it can reset the flag, all following processes cannot enter
> that region. But if process A cannot use flag for indication, how to
> other people know (how to synchronization)?
The simplest approach is to guard the data with a lock.
But if you don't want to do that, another approach is to restrict the
data to one machine word minus one bit, with zero saying that the location
is (as you say) unpolluted. Then you can use a compare-and-swap loop
to update the location only if it is unpolluted.
But maybe you need more data. If so, you can have the data separately
(perhaps dynamically allocated, perhaps not, your choice), and then use
the compare-and-swap method above where NULL says unpolluted.
In some cases, an array-based FIFO queue works better. There is a huge
number of subtlely different FIFOs.
And so on...
Thanx, Paul
next prev parent reply other threads:[~2017-08-04 19:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-04 14:52 synchronization between two process without lock Yubin Ruan
2017-08-04 15:57 ` Yubin Ruan
2017-08-04 19:50 ` Paul E. McKenney [this message]
2017-08-05 1:02 ` Yubin Ruan
2017-08-07 16:48 ` Yubin Ruan
2017-08-07 16:57 ` Paul E. McKenney
2017-08-08 2:12 ` Yubin Ruan
2017-08-08 9:42 ` Junchang Wang
2017-08-23 18:30 ` Yubin Ruan
2017-08-31 22:10 ` Paul E. McKenney
2017-09-01 1:53 ` Yubin Ruan
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=20170804195049.GF3730@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=ablacktshirt@gmail.com \
--cc=perfbook@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.