lkml.org 
[lkml]   [2017]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v3 1/3] lockdep: Make LOCKDEP_CROSSRELEASE configs all part of PROVE_LOCKING
Peter, I'll read your email tomorrow, just one note...

On 08/22, Peter Zijlstra wrote:
>
> Also^2, TJ, what's the purpose of using atomic_long_t for work->data?
> All it ever seems to do is atomic_long_read() and atomic_long_set(),

plust set/clear bit, for example

test_and_set_bit(WORK_STRUCT_PENDING_BIT, work_data_bits(work));

commit a08727bae727fc2ca3a6ee9506d77786b71070b3
Author: Linus Torvalds <torvalds@woody.osdl.org>
Date: Sat Dec 16 09:53:50 2006 -0800

Make workqueue bit operations work on "atomic_long_t"

On architectures where the atomicity of the bit operations is handled by
external means (ie a separate spinlock to protect concurrent accesses),
just doing a direct assignment on the workqueue data field (as done by
commit 4594bf159f1962cec3b727954b7c598b07e2e737) can cause the
assignment to be lost due to lack of serialization with the bitops on
the same word.

So we need to serialize the assignment with the locks on those
architectures (notably older ARM chips, PA-RISC and sparc32).

So rather than using an "unsigned long", let's use "atomic_long_t",
which already has a safe assignment operation (atomic_long_set()) on
such architectures.

This requires that the atomic operations use the same atomicity locks as
the bit operations do, but that is largely the case anyway. Sparc32
will probably need fixing.

Architectures (including modern ARM with LL/SC) that implement sane
atomic operations for SMP won't see any of this matter.

Oleg.

\
 
 \ /
  Last update: 2017-08-22 18:00    [W:0.142 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site