https://forge.codesys.com/forge/talk/Engineering/thread/4dc79156b5/2022-11-04T19:20:23.800000ZRecent posts to Are SysTimeRtc* functions expected to be reentrant?2022-11-04T19:20:23.800000Z2022-11-04T19:20:23.800000Zvicshttps://forge.codesys.com/u/vics/https://forge.codesys.com92de669a32b5c9b694e5b5d25c1f1cbe15ae6551

<div class="markdown_content"><p>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.</p></div>

2022-11-04T18:36:07.514000Z2022-11-04T18:36:07.514000Zh-hermsenhttps://forge.codesys.com/u/hermsen/https://forge.codesys.comfcc709b74c58a4af9932e030938a413d09fc0c76

<div class="markdown_content"><p>why not run this function only once in the most highest prio (or fastest) task and share the outcome via a global var.</p></div>

2022-11-02T15:39:13.264000Z2022-11-02T15:39:13.264000Zvicshttps://forge.codesys.com/u/vics/https://forge.codesys.comf8119482a65d01138c9379736ece5d9a7b472f0e

<div class="markdown_content"><p>If I remember correctly, I wrapped the methods and put a giant lock/semaphore around the system calls.</p></div>

2021-11-30T08:56:00.197000Z2021-11-30T08:56:00.197000ZFPawlakhttps://forge.codesys.com/u/fpawlak/https://forge.codesys.com4ac43ec4b01c2d4c9daf0db1f240671b8d9e720c

<div class="markdown_content"><p>Hi, I have very similar issue on Wago PFC200 (750-8212 and 750-8202).<br/> 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.<br/> 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.<br/> Maybe someone can check it on 'clear codesys' with codesys runtime.</p></div>

2021-06-01T07:38:35.526000Z2021-06-01T07:38:35.526000Zlennartthttps://forge.codesys.com/u/lennartt/https://forge.codesys.comb4ae221fed2d0fc5a4ece4624ebd4446c6d54c49

<div class="markdown_content"><p>Hi Vic<br/> seems like we are facing a similar problem using the SysTimeRtcGetTimezone function in multiple tasks, resulting in access violations. Did you solve it?<br/> Thanks <br/> Lennart</p></div>

2020-07-08T18:39:17.973000Z2020-07-08T18:39:17.973000Zvicshttps://forge.codesys.com/u/vics/https://forge.codesys.com9bbe3f86feb09a8d0d8c25337e9452ca63fc8c0a

<div class="markdown_content"><p>Good afternoon</p> <p>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. </p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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. </p> <p>Thanks<br/> Vic</p></div>