Welcome to our new forum
All users of the legacy CODESYS Forums, please create a new account at account.codesys.com. But make sure to use the same E-Mail address as in the old Forum. Then your posts will be matched. Close

Are SysTimeRtc* functions expected to be reentrant?

vics
2020-07-08
2022-11-04
  • vics - 2020-07-08

    Good afternoon

    I have an application with several tasks that utilizes the SysTimeRtc* family of functions. The initial problem I encountered was that the SysTimeRtcConvertHighResToLocal function would not properly convert the UTC time to local time. The converted time that was being returned was always for the UTC time zone.

    During the debugging process I discovered that the SysTimeRtcGetTimezone function was returning the timezone as UTC even though the PLC was properly configured with the appropriate time zone.

    Digging further, I narrowed the issue down to the runtime somehow getting corrupted when multiple tasks call the SysTimeRtc* functions concurrently. Specifically, calling SysTimeRtcGetTimezone from multiple tasks causes the runtime to raise an AccessViolation exception.

    Once corrupted, the runtime needs to be restarted. No issues with UTC to local timezone conversations are encountered with only one task using the functions.

    My question is whether or not the SysTimeRtc* functions are expected to be reentrant and if not is there documentation specifying which functions are or are not thread-safe.

    Thanks
    Vic

     
    • lennartt - 2021-06-01

      Hi Vic
      seems like we are facing a similar problem using the SysTimeRtcGetTimezone function in multiple tasks, resulting in access violations. Did you solve it?
      Thanks
      Lennart

       
      • vics - 2022-11-02

        If I remember correctly, I wrapped the methods and put a giant lock/semaphore around the system calls.

         
  • FPawlak - 2021-11-30

    Hi, I have very similar issue on Wago PFC200 (750-8212 and 750-8202).
    I using directly only one thread. But I think that same 'internal processes' are also using this function. For example I've started to have 'access violation' when I added 'Trend recording' - it's working in another thread.
    As workaround I can use Wago library, but it is not optimal/universal resolution. I always try to write 'vendor-independent' code as much as possible.
    Maybe someone can check it on 'clear codesys' with codesys runtime.

     
  • hermsen

    hermsen - 2022-11-04

    why not run this function only once in the most highest prio (or fastest) task and share the outcome via a global var.

     
    • vics - 2022-11-04

      On any preemptive multitasking system you will still have a race condition unless the operation of getting the data is an atomic operation. So you still end up with a need to address this race condition.

       

Log in to post a comment.