Locking for bcm2835 library?

Question

I'm using adafruit's DHT22 temperature and humidity sensor, with a modified version of their driver, which in turn uses this bcm2835 library. My modification is that, instead of bailing on failure to read cleanly (which seemed to me to be all too frequent - frequently getting a checksum failure multiple times out of 10 or 20 runs), it tries again.

When I run this repeatedly (every 2 seconds, from another program that updates an LCD display with the results), I am in rare instances (though I can make them less rare, by tweaking how things get run) getting into a situation where there are two (or more) instances of the program running, and neither seems to be getting anywhere, thus effectively causing my display program to block, and not be updated. If I kill both programs, then (up to) 2 seconds later, a new instance is run, and that works fine, so I'm pretty sure this is just a case of the two programs clobbering each other.

What I'd ideally like is for there to be some sort of mutex lock on the access, which I think and hope would simply prevent this scenario (the second instance might block, but the first instance would eventually get its data and succeed).

My question, then, is what would be some reasonable ways I could do this locking, either inside or outside of the bcm2835 library?

I found this related question, though it's doing things in assembler, and the bcm2835 library seems to be pure C code.

Thoughts I've considered are:

1. Adding a new call within the library that uses flock on the fd for /dev/mem. This seems like it may be problematically low-granularity - taking a lock on the whole /dev/mem mapping.
2. The same, but using some other method (which I'm not sure I know if/how this can be done), which would acquire a mutex just for the specific mapped address space relevant to the pin being accessed within e.g. bcm2835_gpio_fsel. This strikes me as my ideal, I'm just not sure how to accomplish it.
3. Something custom to my application, and not related to /dev/mem at all. This strikes me as a bit of a hack, but might be the easiest to do.

So, any thoughts on best practices, and/or ways to accomplish option 2 above? Thanks.

Answer 1

I presume all the programs use your driver to access the display. If so then the locking mechanism is all up to you. You can define your own locking file (e.g. /var/run/.bcm_lock) and use that to control access using the familiar flock.