Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1685759 > unrolled thread

Re: [RFC][PATCH]: documentation,atomic: Add a new atomic_t document

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC][PATCH]: documentation,atomic: Add a new atomic_t document Boqun Feng <boqun.feng@gmail.com> - 2017-07-12 15:00 +0200
    Re: [RFC][PATCH]: documentation,atomic: Add a new atomic_t document Peter Zijlstra <peterz@infradead.org> - 2017-07-12 15:10 +0200
      Re: [RFC][PATCH]: documentation,atomic: Add a new atomic_t document "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-12 21:20 +0200

#1685759 — Re: [RFC][PATCH]: documentation,atomic: Add a new atomic_t document

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jun 12, 2017 at 04:49:29PM +0200, Peter Zijlstra wrote:
[...]
> -Any atomic operation that modifies some state in memory and returns information
> -about the state (old or new) implies an SMP-conditional general memory barrier
> -(smp_mb()) on each side of the actual operation (with the exception of
> -explicit lock operations, described later).  These include:
> -
> -	xchg();
> -	atomic_xchg();			atomic_long_xchg();
> -	atomic_inc_return();		atomic_long_inc_return();
> -	atomic_dec_return();		atomic_long_dec_return();
> -	atomic_add_return();		atomic_long_add_return();
> -	atomic_sub_return();		atomic_long_sub_return();
> -	atomic_inc_and_test();		atomic_long_inc_and_test();
> -	atomic_dec_and_test();		atomic_long_dec_and_test();
> -	atomic_sub_and_test();		atomic_long_sub_and_test();
> -	atomic_add_negative();		atomic_long_add_negative();
> -	test_and_set_bit();
> -	test_and_clear_bit();
> -	test_and_change_bit();
> -

The bit related operations are removed from memory-barriers.txt, I think
we'd better add them in atomic_t.txt? By "them", I mean:

	test_and_{set,clear,change}_bit() as RMW atomic

	{set,clear,change}_bit() as non-RMW atomic

	test_and_set_bit_lock()
	clear_bit_unlock() as non-RMW(but barrier-like) atomic

Regards,
Boqun

[toc] | [next] | [standalone]

#1685765

On Wed, Jul 12, 2017 at 08:53:47PM +0800, Boqun Feng wrote:
> On Mon, Jun 12, 2017 at 04:49:29PM +0200, Peter Zijlstra wrote:
> [...]
> > -Any atomic operation that modifies some state in memory and returns information
> > -about the state (old or new) implies an SMP-conditional general memory barrier
> > -(smp_mb()) on each side of the actual operation (with the exception of
> > -explicit lock operations, described later).  These include:
> > -
> > -	xchg();
> > -	atomic_xchg();			atomic_long_xchg();
> > -	atomic_inc_return();		atomic_long_inc_return();
> > -	atomic_dec_return();		atomic_long_dec_return();
> > -	atomic_add_return();		atomic_long_add_return();
> > -	atomic_sub_return();		atomic_long_sub_return();
> > -	atomic_inc_and_test();		atomic_long_inc_and_test();
> > -	atomic_dec_and_test();		atomic_long_dec_and_test();
> > -	atomic_sub_and_test();		atomic_long_sub_and_test();
> > -	atomic_add_negative();		atomic_long_add_negative();
> > -	test_and_set_bit();
> > -	test_and_clear_bit();
> > -	test_and_change_bit();
> > -
> 
> The bit related operations are removed from memory-barriers.txt, I think
> we'd better add them in atomic_t.txt? By "them", I mean:
> 
> 	test_and_{set,clear,change}_bit() as RMW atomic
> 
> 	{set,clear,change}_bit() as non-RMW atomic
> 
> 	test_and_set_bit_lock()
> 	clear_bit_unlock() as non-RMW(but barrier-like) atomic

I was thinking maybe a separate file, as I was hoping to eventually
write a separate file on spinlocks too.

I'd like to keep the the new thing purely about the atomic* family of
stuff, that's large enough as is.

[toc] | [prev] | [next] | [standalone]

#1685983

On Wed, Jul 12, 2017 at 03:08:26PM +0200, Peter Zijlstra wrote:
> On Wed, Jul 12, 2017 at 08:53:47PM +0800, Boqun Feng wrote:
> > On Mon, Jun 12, 2017 at 04:49:29PM +0200, Peter Zijlstra wrote:
> > [...]
> > > -Any atomic operation that modifies some state in memory and returns information
> > > -about the state (old or new) implies an SMP-conditional general memory barrier
> > > -(smp_mb()) on each side of the actual operation (with the exception of
> > > -explicit lock operations, described later).  These include:
> > > -
> > > -	xchg();
> > > -	atomic_xchg();			atomic_long_xchg();
> > > -	atomic_inc_return();		atomic_long_inc_return();
> > > -	atomic_dec_return();		atomic_long_dec_return();
> > > -	atomic_add_return();		atomic_long_add_return();
> > > -	atomic_sub_return();		atomic_long_sub_return();
> > > -	atomic_inc_and_test();		atomic_long_inc_and_test();
> > > -	atomic_dec_and_test();		atomic_long_dec_and_test();
> > > -	atomic_sub_and_test();		atomic_long_sub_and_test();
> > > -	atomic_add_negative();		atomic_long_add_negative();
> > > -	test_and_set_bit();
> > > -	test_and_clear_bit();
> > > -	test_and_change_bit();
> > > -
> > 
> > The bit related operations are removed from memory-barriers.txt, I think
> > we'd better add them in atomic_t.txt? By "them", I mean:
> > 
> > 	test_and_{set,clear,change}_bit() as RMW atomic
> > 
> > 	{set,clear,change}_bit() as non-RMW atomic
> > 
> > 	test_and_set_bit_lock()
> > 	clear_bit_unlock() as non-RMW(but barrier-like) atomic
> 
> I was thinking maybe a separate file, as I was hoping to eventually
> write a separate file on spinlocks too.
> 
> I'd like to keep the the new thing purely about the atomic* family of
> stuff, that's large enough as is.

As long as wherever the information is kept actually gets updated when
new functions are added or old ones change, I am good.

							Thanx, Paul

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web