What is the difference between semaphores placed in shared memory through mmap and semaphores directly in kernel space?

in the code on page 253 of the second edition of Unix Network programming Volume II: interprocess Communication (Chinese version), the author stores the semaphore in a shared memory through mmap, and then the parent and child processes can directly manipulate the memory to obtain the semaphore (I don"t know if I understand it correctly). However, the kernel should still operate on this semaphore behind its back at this time, right? After all, the sem_wait function is called on semaphores in shared memory. Assuming I understand correctly, what"s the point of putting a semaphore in shared memory?
if what I understand is wrong, I hope seniors can point out?

Linux-kernel operating-system linux c

Jul.22,2021

in fact, the book is only to demonstrate the use of semaphores, in addition to the use of named semaphores, or the use of memory-based semaphores. There is no need to worry about the difference between the two, just the difference in usage.

to go further, a semaphore is actually a counter, and the semaphore used by programs outside the kernel is also used to judge a value by system call to the kernel. If it is greater than 0, it does not wait. If it is equal to 0, it waits for someone to up and wake up the waiting process.

to put it bluntly, no matter how you program, you can use the semaphore as long as you can get the semaphore, whether it's in the shared memory area or somewhere else.

Previous: On the problem of vue-router interceptor

Next: How do I make the directory on the left in Sublime 3 show Git modified files like the atom tag?