search for: atomic_add

...Yasskin <jyasskin at google.com> wrote: > To be clear, Chandler wasn't suggesting any change to the existing > load and store instructions. Instead, we were wondering if people like > the idea of _new_ atomic_load, atomic_store, atomic_cmpxchg, and maybe > atomic_exchange and atomic_add instructions. I see, in that case, I don't have any strong opinion. Maybe new instructions would be simpler and cleaner... I quite like the idea of having more expressive atomic operators, as it'll be easier to map high-level synchronization concepts to IR. cheers, --renato http://syste...

...t; than they are today, and reading them could prove a challenge. To be clear, Chandler wasn't suggesting any change to the existing load and store instructions. Instead, we were wondering if people like the idea of _new_ atomic_load, atomic_store, atomic_cmpxchg, and maybe atomic_exchange and atomic_add instructions. > IMHO, we should keep it simple. I agree that multi-task is ubiquitous > nowadays but the detailed implementation might vary considerably from > language to language and making it explicit only helps, at least in > the beginning. > > cheers, > --renato

...n at google.com> wrote: > > To be clear, Chandler wasn't suggesting any change to the existing > > load and store instructions. Instead, we were wondering if people like > > the idea of _new_ atomic_load, atomic_store, atomic_cmpxchg, and maybe > > atomic_exchange and atomic_add instructions. > > I see, in that case, I don't have any strong opinion. Maybe new > instructions would be simpler and cleaner... > > I quite like the idea of having more expressive atomic operators, as > it'll be easier to map high-level synchronization concepts to IR. I...

On 26 April 2010 10:49, Chandler Carruth <chandlerc at google.com> wrote: > Certainly for languages such as Java, they will make up a surprisingly large > chunk of the loads and stores, and instructions have much mor flexibility in > terms of syntax. On the flip side, it's a lot of plumbing IIRC, and we'd > really need to stick to the very minimal set of operations,

...ch_and_add (&(x)->atomic, 1)) -# define atomic_dec_and_test(x) (__sync_fetch_and_add (&(x)->atomic, -1) == 1) +# define atomic_inc_return(x) (__sync_add_and_fetch (&(x)->atomic, 1)) +# define atomic_dec_and_test(x) (__sync_add_and_fetch (&(x)->atomic, -1) == 0) # define atomic_add(x, v) ((void) __sync_add_and_fetch(&(x)->atomic, (v))) # define atomic_dec(x, v) ((void) __sync_sub_and_fetch(&(x)->atomic, (v))) # define atomic_cmpxchg(x, oldv, newv) __sync_val_compare_and_swap (&(x)->atomic, oldv, newv) @@ -68,6 +69,7 @@ typedef struct { # define atomic_...

...atomic_set(x, val) ((x)->atomic = (val)) # define atomic_inc(x) ((void) __sync_fetch_and_add (&(x)->atomic, 1)) +# define atomic_inc_return(x) (__sync_add_and_fetch (&(x)->atomic, 1)) # define atomic_dec_and_test(x) (__sync_fetch_and_add (&(x)->atomic, -1) == 1) # define atomic_add(x, v) ((void) __sync_add_and_fetch(&(x)->atomic, (v))) # define atomic_dec(x, v) ((void) __sync_sub_and_fetch(&(x)->atomic, (v))) @@ -68,6 +69,7 @@ typedef struct { # define atomic_read(x) AO_load_full(&(x)->atomic) # define atomic_set(x, val) AO_store_full(&(x)->atom...

...fetch (&(x)->atomic, 1)) > +# define atomic_dec_and_test(x) (__sync_add_and_fetch (&(x)->atomic, -1) == 0) The atomic_dec_and_test change seems like unrelated bugfix. Split it out perhaps ? Introduction of atomic_inc_return could/should be a separate commit as well. > # define atomic_add(x, v) ((void) __sync_add_and_fetch(&(x)->atomic, (v))) > # define atomic_dec(x, v) ((void) __sync_sub_and_fetch(&(x)->atomic, (v))) > # define atomic_cmpxchg(x, oldv, newv) __sync_val_compare_and_swap (&(x)->atomic, oldv, newv) > @@ -68,6 +69,7 @@ typedef struct { &g...

...and_fetch (&(x)->atomic, 1)) >> +# define atomic_dec_and_test(x) (__sync_add_and_fetch (&(x)->atomic, -1) == 0) > The atomic_dec_and_test change seems like unrelated bugfix. Split it > out perhaps ? Not a bug fix, just swapping the order.. - atomic_fetch_and_add(-1) == 1 + atomic_add_and_fetch(-1) == 0 > Introduction of atomic_inc_return could/should be a separate commit as well. >> # define atomic_add(x, v) ((void) __sync_add_and_fetch(&(x)->atomic, (v))) >> # define atomic_dec(x, v) ((void) __sync_sub_and_fetch(&(x)->atomic, (v))) >>...

...graph, what > is the difference between the existing "willreturn" and the proposed > "willprogress"? Furthermore, if there is a difference, why is it > relevant to the compiler? I mean there is plenty of cases where you have one but not the other: ``` while (1) {   atomic_add(X, 1); } ``` does make progress but will not return. More importantly, willreturn is a property we derive, willprogress is a property of the input language embedded in the IR. We can use the latter to derive the former, sure, but only one of them is rooted in (high-level) language semantics. We wa...

...} > -static inline void atomic_dec(uint32_t *v) { ia64_fetchadd4_rel(v, -1); } > -#elif defined(__arm__) > +#if defined(__arm__) > static inline void atomic_inc(uint32_t *v) > { > unsigned long tmp; > int result; > > - __asm__ __volatile__("@ atomic_add\n" > + __asm__ __volatile__("@ atomic_inc\n" > "1: ldrex %0, [%3]\n" > " add %0, %0, #1\n" > " strex %1, %0, [%3]\n" > @@ -130,7 +121,7 @@ static inline void atomic_dec(uint32_t *v) > unsigned long...

...vice *device_ctx; - unsigned long avail; + atomic_t avail; struct delayed_work dwork; }; @@ -118,8 +119,9 @@ static void netvsc_xmit_completion(void *context) dev_kfree_skb_any(skb); - net_device_ctx->avail += num_pages; - if (net_device_ctx->avail >= PACKET_PAGES_HIWATER) + atomic_add(num_pages, &net_device_ctx->avail); + if (atomic_read(&net_device_ctx->avail) >= + PACKET_PAGES_HIWATER) netif_wake_queue(net); } } @@ -133,7 +135,7 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net) /* Add 1 for skb->data and additional...

...vice *device_ctx; - unsigned long avail; + atomic_t avail; struct delayed_work dwork; }; @@ -118,8 +119,9 @@ static void netvsc_xmit_completion(void *context) dev_kfree_skb_any(skb); - net_device_ctx->avail += num_pages; - if (net_device_ctx->avail >= PACKET_PAGES_HIWATER) + atomic_add(num_pages, &net_device_ctx->avail); + if (atomic_read(&net_device_ctx->avail) >= + PACKET_PAGES_HIWATER) netif_wake_queue(net); } } @@ -133,7 +135,7 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net) /* Add 1 for skb->data and additional...

...wrote: > > > To be clear, Chandler wasn't suggesting any change to the existing > > > load and store instructions. Instead, we were wondering if people like > > > the idea of _new_ atomic_load, atomic_store, atomic_cmpxchg, and maybe > > > atomic_exchange and atomic_add instructions. > > > > I see, in that case, I don't have any strong opinion. Maybe new > > instructions would be simpler and cleaner... > > > > I quite like the idea of having more expressive atomic operators, as > > it'll be easier to map high-level synch...

...\ - do { \ - if ( (y) < (sizeof(perfcounters.x) / sizeof(*perfcounters.x)) ) \ - atomic_inc(&perfcounters.x[y]); \ - } while ( 0 ) -#define perfc_add(x,y) atomic_add((y), &perfcounters.x[0]) -#define perfc_addc(x,y) atomic_add((y), &perfcounters.x[smp_processor_id()]) -#define perfc_adda(x,y,z) \ - do { \ - if ( (y) < (sizeof(perfc...

...e value of @v to @i. */ #define _atomic_set(v,i) (((v).counter) = (i)) -#define atomic_set(v,i) write_atomic(&((v)->counter), (i)) +static inline void atomic_set(atomic_t *v, int i) +{ + /* coverity[incompatible_cast : FALSE] */ + write_atomic(&v->counter, i); +} /** * atomic_add - add integer to atomic variable -- 1.7.10.4

This version fixes three bugs in the 2nd patch of this series that caused kernel BUG when the system was under race. We weren't accounting with t_oustanding_credits correctly, and there were race conditions caused by the fact the I had overlooked the fact that __jbd2_log_wait_for_space() and jbd2_get_transaction() requires j_state_lock to be write locked. Theodore Ts'o (3): jbd2: Use

...o_dev(struct dvobj_priv *dvobj) +static inline struct device *dvobj_to_dev(struct dvobj_priv *dvobj) { /* todo: get interface type from dvobj and the return the dev accordingly */ #ifdef RTW_DVOBJ_CHIP_HW_TYPE @@ -651,14 +651,14 @@ struct adapter { /* define RTW_DISABLE_FUNC(padapter, func) (atomic_add(&adapter_to_dvobj(padapter)->disable_func, (func))) */ /* define RTW_ENABLE_FUNC(padapter, func) (atomic_sub(&adapter_to_dvobj(padapter)->disable_func, (func))) */ -__inline static void RTW_DISABLE_FUNC(struct adapter *padapter, int func_bit) +static inline void RTW_DISABLE_FUNC(stru...

This round implements all of the review comments from V2 and all patches are now acked. Unless there are any objections I intend to apply later this morning. Ian.

On Tue, 2018-06-05 at 10:05 -0700, Nick Desaulniers wrote: > Functions marked extern inline do not emit an externally visible > function when the gnu89 C standard is used. Some KBUILD Makefiles > overwrite KBUILD_CFLAGS. This is an issue for GCC 5.1+ users as without > an explicit C standard specified, the default is gnu11. Since c99, the > semantics of extern inline have changed

On Tue, 2018-06-05 at 10:05 -0700, Nick Desaulniers wrote: > Functions marked extern inline do not emit an externally visible > function when the gnu89 C standard is used. Some KBUILD Makefiles > overwrite KBUILD_CFLAGS. This is an issue for GCC 5.1+ users as without > an explicit C standard specified, the default is gnu11. Since c99, the > semantics of extern inline have changed