Blog
sem_post funkiness on Linux
Date: 9/8/2017
Tags: linux
I moved the Linux implementation of the GThreadEvent class (.h, .cpp) over to the sem_open, sem_post, sem_wait calls a little while back.

Initially I used named semaphores and that seemed to work ok. But after a few weeks I noticed that sometimes the call to sem_post would just quietly NOT increment the semaphore count, while still returning 0 (Success). Which causes the listening thread blocking in sem_wait to never wake up. Crucially this would break the destructor / exit loop of GEventTargetThread.

Googling this didn't turn up anything useful. I believe I was using the API correctly and the documentation is very sparse. Anyway I implemented the semaphores using the sem_init/sem_destroy (anonymous) and it seems to be robust. Still, I'd like to know what the deal is with the named ones. The general pattern of behaviour I would see is:
  • Thread 1: Create using sem_open
  • Thread 2: Block on sem_wait
  • Thread 1: Start shutdown - calls sem_post (returns 0, but no increment) to tell thread 2 that it needs to exit.
  • Thread 2: Still stuck blocking on sem_wait...
Fun times. I checked it under valgrind and no weird memory accesses. Sometimes it would work ok and exit gracefully. But most of the time it would hang.
 
Reply
From:
Email (optional): (Will be HTML encoded to evade harvesting)
Message:
 
Remember username and/or email in a cookie.
Notify me of new posts in this thread via email.
BBcode:
					[q]text[/q]
					[url=link]description[/url]
					[img]url_to_image[/img]
					[pre]some_code[/pre]
[b]bold_text[/b]