Atomics have significant other use besides providing in-system primitives for safe memory updates. They are used for implementing communication with out of system software or hardware following some protocols. For instance, even UP kernel might require a protocol using atomics to communicate with the software-emulated device on SMP hypervisor. Or real hardware might need atomic accesses as part of the proper management protocol. Another point is that UP configurations on x86 are extinct, so slight performance hit by unconditionally use proper atomics is not important. It is compensated by less code clutter, which in fact improves the UP/i386 lifetime expectations. Requested by: Elliott Mitchell <ehem+freebsd@m5p.com>
Details
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
The two comments also need to be removed or adjusted, but that can be done during commit. Yet another generation of hardware/software passes on.
sys/amd64/include/atomic.h | ||
---|---|---|
105–112 | This makes the second sentence of the first paragraph no longer true. The second paragraph became untrue at f4b3640475cec9299517289b7e8731ae26997cfc. I would tend to simply purge the comment, though it could also be adjusted. | |
sys/i386/include/atomic.h | ||
99–106 | Same situation with the identical comment here. |
sys/amd64/include/atomic.h | ||
---|---|---|
164 | Maybe keep the space after the ; so that if anyone looks at the generated assembly it is 'lock; and' vs 'lock;and'? (In examples below you use a space in, e.g. 'lock; cmpxchg'.) Hmm, looks like you did keep the space in i386? |
I was also a bit worried about the losing the space after the "lock;", just I thought removing it could be justified (didn't realize it was still there for i386). Hopefully all the end of line backslashes still line up. I'm assuming that is Phabricator not rendering things correctly.