System V Semaphores: How not to design an API | Hacker News Reader

System V Semaphores: How not to design an API

thejaywalker.net

11 pointsjaywalker5 comments

My OS course was my first real exposure to the depths of UNIX and C. Being used to Python, I quickly got fed up with how archaic and arcane most of the UNIX/C APIs are. I have a feeling that, if it were judged by even somewhat modern software engineering standards, it would be panned.

Care to enlighten us the exact APIs you consider archaic? "Unix/C APIs" isn't exactly precise --- there are the POSIX APIs which are fairly standard that Linux and the BSDs mostly support; in addition, there are the platform-specific APIs that are constantly updated for modern use-cases. I find most of these APIs intuitive and stable.

In contrast, I don't like some of Python's abstractions, the "subprocess" being (IMO) a particularly weird way to abstract a pipe.

There is probably a logical reason to the design and nomenclature of the system. Unfortunately, these things seem to get lost over time. I imagine that in another twenty to thirty years a portion of our current technology will be considered unnecessarily complicated and obfuscated.

   Is it too much to ask to create separate sem_wait()
   and sem_post() methods.

What happens when you want to do a sequence of waits and posts, and you want to do it atomically? You'd have to introduce an extra semaphore to control access to all doing your sequence.

With the semop() function, you put all your desired operations in one array of ops, and make one semop call, which does all the operations atomically.

Yes, that's exactly why I think the "operations" concept was added. But isn't it good to provide extra sem_wait() and sem_post() for most of the rest of us who want a single increment or a decrement? I have yet to find a good use of an array of operations in a single atomic fashion. Neither dining philosophers nor reader-writers need multiple increments/ decrements in one go.

Reply on news.ycombinator.com