>-Original Message-
>From: Ola Liljedahl [mailto:ola.liljed...@arm.com]
>On 28/09/2018, 02:43, "Wang, Yipeng1" wrote:
>
>Some general comments for the various __atomic_store/load added,
>
>1. Although it passes the compiler check, but I just want to confirm that
> if we should u
er ; Ola Liljedahl
>; nd
>Subject: RE: [dpdk-dev] [PATCH 2/4] hash: add memory ordering to avoid race
>conditions
>
>>
>> Some general comments for the various __atomic_store/load added,
>>
>> 1. Although it passes the compiler check, but I just want to confirm that
On 28/09/2018, 02:43, "Wang, Yipeng1" wrote:
Some general comments for the various __atomic_store/load added,
1. Although it passes the compiler check, but I just want to confirm that
if we should use GCC/clang builtins, or if
There are higher level APIs in DPDK to do atomic
>
> Some general comments for the various __atomic_store/load added,
>
> 1. Although it passes the compiler check, but I just want to confirm that if
> we
> should use GCC/clang builtins, or if There are higher level APIs in DPDK to do
> atomic operations?
>
I have used gcc builtins (just like
Some general comments for the various __atomic_store/load added,
1. Although it passes the compiler check, but I just want to confirm that if we
should use GCC/clang builtins, or if
There are higher level APIs in DPDK to do atomic operations?
2. We believe compiler will translate the atomic_st
Only race condition that can occur is - using the key store element
before the key write is completed. Hence, while inserting the element
the release memory order is used. Any other race condition is caught
by the key comparison. Memory orderings are added only where needed.
For ex: reads in the w
6 matches
Mail list logo
