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

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.
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to