blog/content/post/multiprocessing-and-semaphores.md

27 lines
1.8 KiB
Markdown
Raw Normal View History

2019-10-23 18:00:39 +00:00
---
title: "Multiprocessing and Semaphores"
date: 2019-10-23T13:23:11-04:00
draft: true
---
Sometimes in my line of work, I have to work on C code. In particular, one of my company's key applications is an embedded system that gathers transaction data from stores for transmission to our cloud data pipeline. One of the mechanisms we use for reporting errors within our heartbeat protocol, is to write error messages to a Unix named-pipe. That pipe is read by a separate process which then adds those error messages to a message that is packaged and sent to our cloud to be analyzed.
One of the many issues we've come across with this approach, is if the pipe is continuously written to by one process, it is unavailable for writing by another process that may be having legitimate issues. Our solution to throttle writes to the pipe was to use semaphores.
## What's a semaphore?
A semaphore is essentially a counter. When the counter is above 0, everything is fine and dandy. When the counter is equal to 0, we have to wait before we are able to do anything. Semaphores traditionally have two operations as part of thei API: `signal` and `wait`.
### wait
When we call wait on a semaphore, a few things happen. First, we check the count of the semaphore. If the count is 0, we are blocked right there and have to stop doing any work, waiting for the count to rise above 0. If the count is not 0, we will decrement the count and be on our merry way.
### signal
When we call signal on a semaphore, we increment the count of the semaphore. What happens when we increment the semaphore is the next process in line that got stuck waiting for the count to rise above 0 will get to start up, and decrement the count - likely back to 0 - causing more processes to wait until it's finished.
## Named Semaphores
## The approach