[Jamvm-general] Fwd: JamVM condition waits affected by date changes

[Guillermo R. G. <gui...@gm...>]

Hi all,

I have found out that Object.wait is affected by date changes.
Internally JamVM uses pthread_cond_timedwait, which by default uses
(or should use) CLOCK_REALTIME (ref:
http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_cond_timedwait.html).
This means that If some other process changes the system date while a
thread is waiting, then this gets messed up. For example, imagine the
following sequence:

 - Application code calls Object.wait(timeoutValue)
 - JamVM computes a timeout (see monitorWait in lock.c) and calls
pthread_cond_timedwait
 - Some other process changes the date and sets it lets say 1 hour in
the past (or 1 day or...). This could be a manual call to 'date', or a
process setting the date from a GPS receiver, or just anything else
 - Because pthread_cond_timedwait uses CLOCK_REALTIME by default, it
will hang there waiting for the timeout to elapse.

BTW in my setup (embedded ARM board) this problem was not visible with
older versions of glibc. For example it never happened with
glibc-2.16. But there were some changes in the pthread_cond_timedwait
implementation (I believe this one:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=8f861542dd0603bef99e126e509ece89514c1eeb#patch2)
that seem to trigger it.

On a side note, a similar problem was also present in JDK7, not sure
if it has been fixed since then. See this article:
https://bbossola.wordpress.com/2013/09/04/jvm-issue-concurrency-is-affected-by-changing-the-date-of-the-system/

Back to JamVM now: Wouldn't it be a good idea to use CLOCK_MONOTONIC
instead of CLOCK_REALTIME for pthread_cond_timedwait ?

Best,

Guillermo Rodriguez Garcia
gui...@gm...