refactored semaphore-related code

[i-ky]

Should resolve #47:

• moved semaphore-related code into separate source file;
• changed semaphore set creation to use IPC_PRIVATE;
• improved error messages.

[v-zhuravlev]

Would that be hard to develop a simple test to check that port locking is happening? This thing is complex (for me at least) and it would be good to keep under control.

[i-ky]

Do you want a synthetic test or close to real life scenario? If you know which ill effects the absence of locking can have, then we can try to reproduce these effects in tests.

[v-zhuravlev]

When locking is in place - another zabbix process must wait for the first process to finish in order to access the port(resource). Not sure how to test at this point. Ill effects are unpredictable - could be CRC errors, spontaneous timeouts...

[i-ky]

As I understand, the reason of ill effects is that multiple processes can simultaneously write to the same serial port. But it is difficult to guarantee that, because processes belong to Zabbix and actual writing is done by libmodbus. Even without locking the chance of getting any issues is small provided the number of parallel processes is low and port throughput is high. Making a real-life-like test which will 100% fail if there is something wrong with locking mechanism is quite challenging. We will need:

• lots of Zabbix processes;
• lots of parallel requests to the same port;
• simulate a really slow serial port.

Is it possible and is it worth it?

[v-zhuravlev]

Even without locking the chance of getting any issues is small provided the number of parallel processes is low and port throughput is high
In real life it just doesn't work without locking - you would get errors all the time.

I was thinking about some simple test(maybe unit level not integrational like we did befie) to test that locking is happening.

[i-ky]

Depends on #54.