On Thu, Mar 09, 2017 at 10:59:27AM +0100, Alexandre Martins wrote: > I have the save question for the cpu_ipi_pending here: > > https://svnweb.freebsd.org/base/head/sys/x86/x86/mp_x86.c?view=annotate#l1080 > > Le jeudi 9 mars 2017, 10:43:14 Alexandre Martins a ?crit : > > Hello, > > > > I'm curently reading the code of the function smp_rendezvous_action, in > > kern/subr_smp.c file. In that function, i see that the variable > > smp_rv_waiters is read in some while() loop in a non-atomic way. > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annotate#l412 > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annotate#l458 > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annotate#l472 > > > > I suspect one of my freeze to be due by that. You should provide either evidence or, at least, some reasoning supporting your claims. > > > > Should this function be patched to use > > "atomic_load_acq_int(&smp_rv_waiters[])" ? There too. As a side note, any read or write of the naturally aligned integer types with size less or equal than the machine word, on all supported architectures, are atomic. The meaning of the word atomic there is that when reading, you always get a complete value that was written by a writer into this location, not some out of thin air value. Similarly, when writing, you are guaranteed that any observer of the write will see the value you have wrote. The guarantees above hold both for C-level code and for the assembler accesses. atomic_load_acq() provides additional guarantees which do not affect the value read from the variable itself, but establish the ordering on the visibility of the related operations.Received on Thu Mar 09 2017 - 12:08:06 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:10 UTC