On Sep 20, 2014, at 12:12 PM, Daniele Di Proietto <ddiproie...@vmware.com> wrote:
> Sometimes we need to read and write 64-bit values (statistics) from multiple > threads. On 64-bit architectures it si possible to read 64-bit data while it > is > being written without worrying about consistency. > On 32-bit architectures have to use some form of synchronization to make sure > that we are reading a consistent 64-bit value. > > Therefore, 'u64_stats_lock' is introduced, which maps to a noop for 64-bits > architecture and to a mutex for other architectures. Did you consider using atomic variable instead? In some 32-bit systems aligned 64-bit accesses can be also consistent without locking, and there may be other, more efficient mechanisms for ensuring atomicity of single variable access than a mutex. In a single-writer scenario you would not use atomic_add, but a combination of an atomic_read, non-atomic addition, and atomic_store. Optimizer might even combine these to a single instruction? Jarno > > Signed-off-by: Daniele Di Proietto <ddiproie...@vmware.com> > --- > lib/automake.mk | 1 + > lib/u64-stats-lock.h | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 66 insertions(+) > create mode 100644 lib/u64-stats-lock.h > > diff --git a/lib/automake.mk b/lib/automake.mk > index b83cceb..7f265ef 100644 > --- a/lib/automake.mk > +++ b/lib/automake.mk > @@ -234,6 +234,7 @@ lib_libopenvswitch_la_SOURCES = \ > lib/token-bucket.c \ > lib/token-bucket.h \ > lib/type-props.h \ > + lib/u64-stats-lock.h \ > lib/unaligned.h \ > lib/unicode.c \ > lib/unicode.h \ > diff --git a/lib/u64-stats-lock.h b/lib/u64-stats-lock.h > new file mode 100644 > index 0000000..0db40a5 > --- /dev/null > +++ b/lib/u64-stats-lock.h > @@ -0,0 +1,65 @@ > +/* > + * Copyright (c) 2014 Nicira, Inc. > + * > + * Licensed under the Apache License, Version 2.0 (the "License"); > + * you may not use this file except in compliance with the License. > + * You may obtain a copy of the License at: > + * > + * http://www.apache.org/licenses/LICENSE-2.0 > + * > + * Unless required by applicable law or agreed to in writing, software > + * distributed under the License is distributed on an "AS IS" BASIS, > + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. > + * See the License for the specific language governing permissions and > + * limitations under the License. > + */ > + > +#ifndef U64_STATS_LOCK_H > +#define U64_STATS_LOCK_H 1 > + > +#include "ovs-thread.h" > + > +#ifdef __cplusplus > +extern "C" { > +#endif > + > +/* This type of lock should be used for accessing atomically 64-bit values > from > + * multiples threads. It maps to noop when compiling for 64-bit > architectures, > + * otherwise it is a mutex. The basic idea is similar to > linux/u64_stats_sync.h > + */ > + > +#if !__GNUC__ || !defined(__x86_64__) > +#define U64_STATS_LOCK_NEEDS_MUTEX > +#endif > + > +struct OVS_LOCKABLE u64_stats_lock { > +#ifdef U64_STATS_LOCK_NEEDS_MUTEX > + struct ovs_mutex mutex; > +#endif > +}; > + > +static inline void > +u64_stats_lock_acquire(struct u64_stats_lock *l OVS_UNUSED) > + OVS_ACQUIRES(l) > + OVS_NO_THREAD_SAFETY_ANALYSIS > +{ > +#ifdef U64_STATS_LOCK_NEEDS_MUTEX > + ovs_mutex_lock(&l->mutex); > +#endif > +} > + > +static inline void > +u64_stats_lock_release(struct u64_stats_lock *l OVS_UNUSED) > + OVS_RELEASES(l) > + OVS_NO_THREAD_SAFETY_ANALYSIS > +{ > +#ifdef U64_STATS_LOCK_NEEDS_MUTEX > + ovs_mutex_unlock(&l->mutex); > +#endif > +} > + > +#ifdef __cplusplus > +} > +#endif > + > +#endif /* u64-stats-lock.h */ > -- > 2.1.0.rc1 > > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
