为什么在任何知道其名称的进程中，线程都可以使用命名信号量？

Question

From APUE

POSIX semaphores are available in two flavors: named and unnamed. They differ in how they are created and destroyed, but otherwise work the same. Unnamed semaphores exist in memory only and require that processes have access to the memory to be able to use the semaphores. This means they can be used only by threads in the same process or threads in different processes that have mapped the same memory extent into their address spaces. Named semaphores, in contrast, are accessed by name and can be used by threads in any processes that know their names.

Unnamed semaphores "can be used only by threads in the same process or threads in different processes that have mapped the same memory extent into their address spaces", because "Unnamed semaphores exist in memory only".

What is the reason that named semaphores are usable by threads in any processes that know their names?

Thanks.

Answer 1

From man page of sem_overview :

On Linux, named semaphores are created in a virtual file system, normally mounted under /dev/shm, with names of the form sem.somename

So those are accessible for 'threads in any processes' similar way than normal files are.

pthread library may then map those files to memory.

Answer 2

You're thinking about this backwards. The question is: "if I need to synchronize use of a shared resource between teo unrelated processes, hiw do I do it?" And the answer is "you can give a semaphore a name, and then it's not restricted to use in processes which share memory."

Why is that even useful? Well, the use cases may not be common -- perhaps you've never run into one -- but they certainly exist. There are lots of resources which are shared between unrelated processes: databases, configuration files, serial ports, printer queues, and many more. You can mediate between shared uses of these resources with lock files, but it's clunky and you end up reinventing the wheel on every project. Semaphores, on the other hand, are easy to use and have well-defined documented semantics.

However, most uses of semaphores are indeed between related processes which share memory. And you wouldn't want to unnecessarily pay the overhead for maintaining a name in a filesystem.

So we end up with two kinds of semaphores: cheap low-overhead ones which serve the most frequent use cases, and heavier higher-overhead ones which can be used more generally. The nice thing is that the semantics and API are very similar, so you don't need to learn a whole new set of concepts when you start using named semaphores.