in its man-page pthread_mutex_timedlock documents that the absolute timeout parameter should be based on the CLOCK_REALTIME clock or in the system clock. All this depending on whether the 'Timers option' is supported or not.
What do they mean by 'Timers option'? How could I tell for sure what time getter API should I use in my specific platform?
thanks,
Rodrigo
See man clock_gettime.
but that does not help me understand the statement in the pthread_mutex_timedlock man-page. All the examples I have seen around they use clock_gettime with option CLOCK_REALTIME before calling pthread_mutex_timedlock. But this did not work on my platform and what did work was to get the time by means of gettimeofday, convert to timespec and then call pthread_mutex_timedlock.
okay, I did not want to go into the details of my test, because I'm sure this will drive the discussion away from my basic question. How can I tell that in my platform the 'Timers option' (as in pthread_mutex_timedlock's man-page) is available or not?
In what manner did it 'not work' on your platform? runtime error? link error? compiler error? If it's just a runtime error, the obvious way would be to try it and see if it's available.
run time misbehavior. it did timeout much before the absolute time passed as parameter.
ps: something strange here. in my browser I read that your first reply says 'clock_gettime', but in the notification I got via email it says 'clock_getres'.
Ah, so it's not unavailable as much as just not working correctly. To see what's going on I'd need to see the code.
A mistake on my part. I frequently edit my posts.
The term "Timers option" comes from the IEEE Std 1003.1-2004 (The Open Group Base Specifications, Issue 6) standard which was superceeded by IEEE Std 1003.1-2008 (The Open Group Base Specifications Issue 7).
See IEEE Std 1003.1-2004 XBD (Base Definitions) section 1.51 Codes for exact details. Essentially the "Time Options" consisted of optional POSIX.1b (Realtime extension) functionality denoted by the margin notation "[TMR]".
In this particular specification, clock_getres(), clock_gettime(), clock_settime() and more were denoted by [TMR] - hence the appropriate verbiage in the pthread_mutex_timedlock() man page.
I see. So, the sole presence in my environment of functions like clock_gettime should suggest to me that the 'Timers option' is actually available indeed and, therefore, something like this:
clock_gettime(CLOCK_REALTIME, &ts);
ts.tv_sec += 1;
it should work as a one second timeout on pthread_mutex_timedlock. But well, this is exactly what did not work for me (timeout in much less than a second) and the 'Timers option' thing started to call my attention.
I will revisit my implementation here and eventually come back with actual test code for more help 
many thanks,
Rodrigo
Have a look a post I wrote some time ago relating to porting the WIN32 API WaitForSingleObject to GNU/Linux. I show a complete example of clock_getttime() used with pthread_mutex_timedlock() and discuss why pthread_mutex_timedlock() can sometimes fail due to the use of recursive mutexes.