Time FT Meeting Minutes 2026

[lavrovvalera]

2026-02-27 Weekly

Location

Online via zoom: link to the meeting

Participants

@lavrovvalera
@umaucher
@mikehaller
@FScholPer
@BlueXMarv3l
@BjoernAtBosch

Meeting Minutes

Feature Team Lead

• Mondays tech syncs
• Moderating and managing the release
• -> @lavrovvalera

Planning

• Which dashboard to use?
  • it is available here: https://github.com/orgs/eclipse-score/projects/32

PR merging/integrating

• merge the exisiting PRs and then consider others (?)
• requirements
  • how does each pitch cover the requirements
  • Do we need to adjust the requirements
• ASIL label
  • do we need ASIL-B?
• How the PRs could be integrated, more detailed analysis, more "detailed" table -> @mikehaller
• BMW code will be published till 02.03 in bmw score::time pitch time#6
• need to decide the Apps APIs -> also need to consider the needed APIs (except the Now)
• we could consider the discusions from 4 comnponents (create tickets:
  • Define Applications API
  • Needs to consider several use cases. Need some sketch and so on.
  • Passive Now and Notifications API
  • Collect relevant use cases
• Need co consider all artifacts, which are needed for the certification
• shall everything be part of the 1.0 release or split somehow?

System architecture

• Is it QNX * Hyp?
  • QNX8
• Discussion with com
  • the ipc between host and guests -> @mikehaller
• HW support
  • Assumption of use
  • Customisations support
  • could we agree on QNX * Qualcomm?
    • There are many vendors, but Qualcomm wanted to support
  • Discuss with Qualcomm about their support -> @FScholPer
  • ECARX suggested to make the verification for stack on their reference platform. The VPN access to the HW could be provided to the team.

The repo template was updated

• the src -> score (or something)
• template needs to be updated
• need to consider this point as additional efforts (without immediate actions)

Agenda for 05.03

• Decide the next step integration based on the source code (merge strategy)
• Prepare the SAD sketch to visualize the components, responsibilities, which could be used as base to make decisions.
  • -> @lavrovvalera
• Cross-check the SCORE requirements towards tooling (bazel/docascode/license check/...)
  • cpp toolchain to be used
  • need to cross check, that the source code should be built with the new toolchains, so that SCORE env is being used and prepared

[lavrovvalera]

2026-03-06 Weekly

Location

Online via zoom: link to the meeting

Participants

@lavrovvalera
@mikehaller
@anmittag
@BjoernAtBosch
@FScholPer
@gordon9901
Matthias Schulze
peng.zhu@ecarx
pengcaho.zhu
@BlueXMarv3l
@mwx2015

Meeting Minutes

ETAS made the AI-based approach analysis of the 3 pitches.

• S-CORE TIME comparison 2026-03-05 draft.pdf
• AI summary
• manual results aggregation
• review with 4 eyes the report
• results are in the presentation
• BMW is it copy-pasted or done from scratch?
  • score::time interfaces - from production, the rest is done from scratch
• ECARX updated the pitch with some design documents. Part is already in the PR, on the next weekend some design update will come
• ETAS has the large code basein C and a bit cpp17
• Approaches
  1. use BMW as base, cherry pick the ETAS and ECARY on the top
     • API discussions? go to AUTOSAR style or not?
     • What else needs to be done to get it release ready and how long will it take
  2. use ETAS as a base, which should be ready to next SCORE release
     • after this needs to make it nicer. which could be done after the first integration
  3. use ECARX as a base - hard to estimate of the production readiness, some open questions there.
     • mainly rely on performance increase
  4. base on BMW design and fill the components from the different pitches

• Decision

  • ETAS agreed to merge the BMW pitch as base
  • ECARX agreed to merge the BMW pitch as base
  • BMW agreed to merge the BMW pitch as base

• Points

  • What is our target
    • Earlier availability or long term having the best maintainable architecture
      • Agreed on the long term best solution
  • How far do we want to go away from AUTOSAR interfaces?
    • not everybody use the full AUTOSAR interfaces
    • @FScholPer will take a look, in which direction they have implemented it
  • Need to start with APIs and their stubs
  • Requirements coverage
    • main coverage is on the ETAS and on ECARX
    • priority is on the VehicleTime and possibility to scale
  • Create an issue: to bring the BMW to buildable and merge it
    • then define next step -> tickets will be created
    • The rest PRs to close the PR
      • ETAS: in case of needed further adaptations, the new PRs will be opened, code will be copied there with adaptations needed
    • API discussion (#2659):
      • needs a breakout session
    • TimeSlave (#2660)
      • ECARX has it
      • need to evaluate the integration
    • Verification
      • put to the backlog

[lavrovvalera]

2026-03-13 Weekly

Location

Online via zoom: link to the meeting

Participants

@lavrovvalera
An
@BjoernAtBosch
@FScholPer
@gordon9901
Matthias Schulze
pengcaho.zhu
@BlueXMarv3l
@mwx2015

Meeting Minutes

• The BMW PR (bmw score::time pitch time#6) is merged
• Do we need to rename the repo or create the new one?
  • Need to catch up the best practice in the score -> @lavrovvalera
  • Need to find an answer, when the repo should indeed be transferred to the regular modules. -> Shall it be already released to be part of the "normal modules list" or just initial status is enough
  • Within the "normal" module, also all safety processes shall be applied. Suggestion is to work still in inc_repo until fulfilling most of the functional requirements
• Why do we need HighPrecisionLocalSteadyClock interface
  • to work with asil-b ClockCycles
  • to be able to mock the interface and use in the unit and component tests
• There should be also created a new interfaces for absolute time in score/time
  • @lavrovvalera -> create a ticket in the backlog: https://github.com/eclipse-score/score/issues/2690
• Existing APIs in score/time/svt looks like should be fisible enough for the moment. Further discussions might be needed
  • AUTOSAR provides several time bases support. For us svt + abs time (wallclock/realtime/sdat) would be enough for the moment
  • Decision: we can stick to the provided APIs
• The rate deviation between GM and local clock
  • TimeSlave shall somehow adjust the rate and clock value of the local clock
  • That shall be somehow be reflected in the requirements
• TimeSlave
  • ECARX could support here and prepare the TimeSlave -> @BlueXMarv3l , @lavrovvalera -> create a ticket: https://github.com/eclipse-score/score/issues/2691
  • the ptp_machine module could be extended with the library to communicate with the TimeSlave process
  • TimeSlave could not be make the ASIL-B because of the network stack dependencies
  • ASIL-B/QM
    • need to cross check, what is in the requirements -> they are QM
    • Need to check if the requirements are correct in case of ASIL level -> create a ticket -> @lavrovvalera
  • as long as time info forwarding is not so frequent and not time critical several daemons would be fine for that -> TimeSlave could be
    organized as separated daemon
• The solution shall be based on the hw stable local clock.
• It shall be organize as AoU -> need to start to write the AoU document in the time repo -> Create a ticket
• mw::com -> need to check if it makes sense with Ulrich -> @lavrovvalera mainly performance reasons for our use-case
• create an example - client -> @lavrovvalera create ticket, assign to @lavrovvalera : https://github.com/eclipse-score/score/issues/2692
• ITF
  • try to consider the https://github.com/eclipse-score/communication/tree/main/quality/integration_testing
  • need to check if it would make sense to use that on instead of "heavy" ITF
  • create a ticket (epic) and start refining
• requirement
  • @FScholPer to prepare the draft requirement, the offsets between the time bases shall be available
• An could try to test from integration perspective -> create a ticket for that

Agenda for 2026-03-20

• API discussion
• System Requirements
  • ASIL-B/QM?

[lavrovvalera]

Weekly 2026-03-20

Participants

@lavrovvalera
@mikehaller
@gordon9901
pengchao.zhu
@BlueXMarv3l
@mwx2015

MoMs

• Create a vote to shift the weekly meeting at least on 30 mins -> @lavrovvalera
• API discussion: suggestion is to shift to next time (27.03), when @BjoernAtBosch should be available.
• TimeSlave https://github.com/eclipse-score/score/issues/2691:
  • Tracy and her team started working on the component
  • Suggestion: the EMAC update in the hw make optional.- configured via config.
  • hopefully, we could see some results before next sync (27.03)
• mw::com between TimeDaemon and the clients
  • @lavrovvalera will disscuss with Ulrigh and will present the results on 27.03
• System requirements ASIL-B/QM?
  • by default all components in SCORE shall be ASIL-B -> @lavrovvalera to confirm
  • Allocate 1/2 of next sync to update the requirements together -> put to agenda - > @lavrovvalera
• Refinement
  • Suggestion is to do it on the weekly syncs.
  • we could pick on topic, plan it and refine in the session. It means, it needs ot be known beforehand, what are we going to refine
• Vacations
  • @BjoernAtBosch and @mikehaller will be on vacation (in a sequence) because of the Osternferien

[lavrovvalera]

Weekly 2026-03-27

Participants

@lavrovvalera
@BjoernAtBosch

MoMs

• TimeSlave https://github.com/eclipse-score/score/issues/2691
  • the PR is ready for the review: feat: add TimeSlave process and libTSClient shm IPC channel time#8
  • @lavrovvalera ping in slack with review request
• mw::com between TimeDaemon and the client
  • @lavrovvalera still in discussion with Ulrich. The concept to be prepared till next weekly
  • main idea to switch was o reuse the mw::com implementation for standalong OS as well as HYP architecture
  • as long as the update frequency is relatively seldom (~125 msec) and the data inside is handled by the library we don't need "super" performance solution here.
  • another point for mw::com would be, it does support the notification of status changed if it will be needed for the Apps
• API discussion
  • @lavrovvalera the use case documentation (diagram + md file) to address the API discussion
  • main APIs: poling (Now()) and notification APIs
  • question is do we need Autosar-like API, where multiple time bases are supported out from the box
• System requirements ASIL-B/QM
  • shifted to next meeting
• Next Friday (03.04) is public holiday in Germany -> Weekly meeting will be skipped. Next meeting will be on 10th of April
• Agenda for 10.04
  • TimeSlave implementation/presentation
  • mw::com between TimeDaemon and the client
  • System requirements ASIL-B/QM
  • API + use cases discussion
    • @lavrovvalera ask to collect use cases
  • Future refinements

[lavrovvalera]

Weekly 2026-04-10

Participants

@lavrovvalera
@BjoernAtBosch

MoMs

• TimeSlave https://github.com/eclipse-score/score/issues/2691
  • the PR review is ongoing: feat: add TimeSlave process and libTSClient shm IPC channel time#8
• Autosar IP
  • there might be conflicts with Autosar IP in the time domain. Mabye because of the ETAS pull request, guys already updated it. In current solution, merged to the repo, there should be no problems
• @BjoernAtBosch will start working with ITF if it will fit to our integration tests
• @lavrovvalera will prepare the API proposal
• Clarify if the meeting was shifted -> @BjoernAtBosch will ping Christian.

Agenda for 17.04

• TimeSlave implementation/presentation
• mw::com between TimeDaemon and the client
• System requirements ASIL-B/QM
• API + use cases discussion
• @lavrovvalera ask to collect use cases
• Future refinements

[lavrovvalera]

Weekly 2026-04-17

Participants

@lavrovvalera
@BjoernAtBosch
@florianfueller
@gordon9901
@nhzpc122
@BlueXMarv3l

MoMs

• TimeSlave https://github.com/eclipse-score/score/issues/2691
  • the PR review is ongoing: feat: add TimeSlave process and libTSClient shm IPC channel time#8
  • the deadline to merge it is on 24.04 -> we will push merge next meeting.
  • if it will be needed, we could organize additional discussion about the comments. Sync in Slack
• mw::com between TimeDaemon and the client
  • the disign can be "time sync service based on fields"
  • there might just several (or only one field) to carry all time info values or combined by groups (sync data, pdelay data, time info data)
  • aslong as the time, when the app will call the Now() is unpeicatable, library needs to cash the values in oder to release the mw::com context
  • because of caching, no zero copy finaly
  • gap: applciaiton shall model or configure the mw::com, so it will be visible on app level. the goal will be to cover it inside the library only. for that need to create a feature request towards mw::com guys
  • ipc for VM or hosts, is comletely done by modelling and is the build time dependency (different modeling or config could be deployed to image)
  • no need additional propriatory mechanism for ipc inside and outside the ECU/VM
  • no time critical to forward the time info
  • could we give an option to the customer to decide which ipc to use
    • yes, even now it is supported to have different implementaiton between
  • mw::come supports the cross-ECU comminucation, which shall NOT be used in time domain
    • it could be fomulated like AoU
  • in case of HYP, in case guests could be qnx/Android/Linux, there might be a scenario, when guest will not use score colutions, like mw::com. in this case they will need to use their own ptp4l or similar time slaves. That needs to be cross checked -> @BjoernAtBosch
  • @lavrovvalera prepare the detailed activity diagram to use mw::com
  • decision shall be taken next meeting on 24.04
• API + use cases discussion
  • main use cases: Now(), Callback mechanism, Timebase configuration like in autosar
  • @lavrovvalera to finalize the PR and present on 24.04
• System requirements ASIL-B/QM
  • Time library on App side and the communication shall be asil-b
  • If TimeDaemon shall be Asil -B as well
  • Need to go trough the system reqs and figure out which of them should be considierd as asil-b. @lavrovvalera @BjoernAtBosch
• Future refinements (create tickets for)
  • verifications between the release. @lavrovvalera create an epic for verificaiton.
  • Plan to discuss this topic to have an output: which steps are needed to come to first ITF, on which env, what the gaps. result shall be the tickets to be implemented. @lavrovvalera put to agenda on CW18
• on 01.05 is public holiday in Germany and China. we need to find another timeslot on the CW 18. @lavrovvalera organize a poll on slack

Agenda for 24.04

• 2merge: TimeSlave https://github.com/eclipse-score/score/issues/2691
• 2decide: mw::com between TimeDaemon and the client
• API + use cases discussion
• System requirements ASIL-B/QM

[lavrovvalera]

Weekly 2026-04-24

Participants

@BjoernAtBosch
Matthias Schulze
@BlueXMarv3l
@gordon9901
@florianfueller

MoMs

• TimeSlave feat: add TimeSlave process and libTSClient shm IPC channel time#8
  • need to merge it if there is no veto
  • create a ticket to use base libs in the shmem handling, based on comment feat: add TimeSlave process and libTSClient shm IPC channel time#8 (comment)
  • No decision to merge, because consent of @lavrovvalera was unclear
  • Objection by @BjoernAtBosch: Should we move all kind evaluation (e.g. calculation of path delay) from TimeSlave to TimeDaemon? Reason: TimeSlave could be only QM and isn't free of interference.
• 2decide: mw::com between TimeDaemon and the client
  • Undecided
  • @BjoernAtBosch: Objection (after discussion with architect):
    • With using mw::com, any update of timesync information needs to be notified to each application involved causing some overhead.
    • Unclear is the sizing of the message queues: In case of timesync, clients do not need a "history" of all received updates - only the last update is relevant. If we limit queue size to 1, the question arises if this will be always updated the latest information (even if any application did not yet read the previous update) or if the new update is lost as long as there is some older, not yet read content.
    • Advantage of the current shared memory solution: Timesync info is maintained in a single place updated by the daemon and all apps access it if needed without any overhead.
    • A possible update notification of the sync status would still need to be done via mw::com, of course
• API + use cases discussion
  • shifted to next weekly
  • @BlueXMarv3l: API should be defined in C++ and Rust to support both languages
  • @BjoernAtBosch: "Quick draw": Two basic options possible:
    • Rust API is using some interfacing to the C++ solution
    • Having two separate library implementations - seems to be the better option because of the limited functionality of the library
• System requirements ASIL-B/QM
  • Shifted to next weekly
  • @BjoernAtBosch: Our architect suggested to do a HARA and later an FMEA to determine this
• Testing:
  • @BlueXMarv3l mentioned that a clear test case description of the overall end-to-end test case is missing

Agenda for ??.04

• API + use cases discussion
• System requirements ASIL-B/QM
• Verification epic: which steps are needed to come to first ITF, on which env, what the gaps. result shall be the tickets to be implemented. The ticket: Feature Verification time#17

[BjoernAtBosch]

Wrote this as "minutes of my memory". @BlueXMarv3l please feel free to add missing or correct misunderstood things. Thx!

[lavrovvalera]

Weekly 2026-04-30

Participants

@lavrovvalera
@BjoernAtBosch
@florianfueller
Matthias Schulze

MoMs

• TimeSlave PR
  • feat: add TimeSlave process and libTSClient shm IPC channel time#8
  • to merge it we need somebody with write acces (@FScholPer , @umaucher )
• 2decide: mw::com between TimeDaemon and the client
  • Objection from prev meeting:
    • With using mw::com, any update of timesync information needs to be notified to each application involved causing some overhead.
    • Unclear is the sizing of the message queues: In case of timesync, clients do not need a "history" of all received updates - only the last update is relevant. If we limit queue size to 1, the question arises if this will be always updated the latest information (even if any application did not yet read the previous update) or if the new update is lost as long as there is some older, not yet read content.
    • Advantage of the current shared memory solution: Timesync info is maintained in a single place updated by the daemon and all apps access it if needed without any overhead.
    • A possible update notification of the sync status would still need to be done via mw::com, of course
  • open quesiotns (main advantages):
    • what to do with the HYP design
      • to allocate the shmem we ned to use differnt QNX API-> ned to have another impl to allocate the memory, which could be configured.
    • mw::com solution is already asil-b
  • how to come to the decision?
    • @lavrovvalera : notify in slack, next time we need to come to some decision.
    • we need to ake the concept (2 concepts) and compare the siolutions. @lavrovvalera + @florianfueller
• API + use cases discussion
  • PR is repared Prepare the new score::time API time#18
    • docs: https://eclipse-score.github.io/inc_time/pr-18/time/index.html
    • some cleaning are still needed, but is ready for the first review.
• System requirements ASIL-B/QM
  • How to makethe asil-b reqs without HARA?
• Verification
• @lavrovvalera to cretae a list of possible gaps in implementation
• @lavrovvalera to create a ticket to fix the QNX build, currently there is a license issue. -> assign to @BjoernAtBosch
• @lavrovvalera to create a ticket to make the HW clock manipulation n a stakeholder level a bit more clear

Agenda for 07.05

[lavrovvalera]

Weekly 2026-05-07

Participants

@lavrovvalera
@BjoernAtBosch
@florianfueller
@BlueXMarv3l
@gordon9901

MoMs

• TimeSlave PR is merged

• 2decide: mw::com between TimeDaemon and the client -> shift to next weekly

• Next weekly on 15.05 is a bridge day in Germany. Then we skip the meeting next week and meet next time on 22.05

• API + use cases discussion

  • main concern is about namings and design
  • main idea that the Tags shall fit to the real vehicle scenaious: Vehicle time (ptp), System_time -> sync to some absolute external time base
  • need to add the AbsTime (AbsoluteTime?) as additional tag. @lavrovvalera -> add into proposal, how it could be implemented.
    • the AbseTime should not be mapped to td:.chrono::system_clock, because the in the linux there might be a problem with the leap seconds.
  • Discussion with namings could be done offline.
  • Do we need some additional interfaces to different time_bases? In autosar there was a possibility to add some just via configuraiton.
    • At the moment, we don't have in mind any additional timebases or use cases where we need it.
    • proposal to think about that till next meeting.

• System requirements ASIL-B/QM

  • shift to next meeting

• Folder and namings updaze: the modlue template for folder structure was updated. we need to be complient wit hit. the epic was created: Support SCORE Code Structure & Conventions time#19

  • @lavrovvalera to cretae a ticket for TimeSlave -> assign to @BlueXMarv3l : Improvement: Update the TimeSlave to comply to SCORE conventions  time#20
  • @lavrovvalera to create a ticket for the TimeDameon -> assign to @BjoernAtBosch : Improvement: Update the TimeDaemon to comply to SCORE conventions time#21

• Make the chain runnable (PoC level)

  • We need to have the example client application -> @BlueXMarv3l : Improvement: Add the example to show the score::time interfaces usage time#13
  • Run the chain on the hw -> @BlueXMarv3l

• Verification (first smoke test)

  • Using the working chain (see prev epic) Need to cretae the 1st ITF test and be able ru nit manually and on CI. @lavrovvalera to find the existing example
  • we need to consider the tests, based on input from @gordon9901 feat: add TimeSlave process and libTSClient shm IPC channel time#8 (comment) -> move them to the Verificaiton strategy to the repo -> @BlueXMarv3l , @lavrovvalera to create a ticket about it.

• Qnx license (build) shift to next meeting

  • @lavrovvalera to create a ticket to fix the QNX build, currently there is a license issue. -> assign to @BjoernAtBosch

[lavrovvalera]

Weekly 2026-05-22

Participants

@lavrovvalera
@BjoernAtBosch
@NEOatNHNG
@gordon9901
@mikehaller
@BlueXMarv3l

MoMs

• Backlog
  • need to add the epic about mw::com discussion
• mw::com
  • Objection from prev meeting:
    • With using mw::com, any update of timesync information needs to be notified to each application involved causing some overhead.
    • Unclear is the sizing of the message queues: In case of timesync, clients do not need a "history" of all received updates - only the last update is relevant. If we limit queue size to 1, the question arises if this will be always updated the latest information (even if any application did not yet read the previous update) or if the new update is lost as long as there is some older, not yet read content.
    • Advantage of the current shared memory solution: Timesync info is maintained in a single place updated by the daemon and all apps access it if needed without any overhead.
    • A possible update notification of the sync status would still need to be done via mw::com, of course
    • open quesiotns (main advantages):
      • what to do with the HYP design
      • to allocate the shmem we ned to use differnt QNX API-> ned to have another impl to allocate the memory, which could be configured.
    • mw::com solution is already asil-b
  • Field works as notifications. need to use then field with event (without get/set)
  • get - >method call fro mthe daemon -> additional overhead
  • mw::com will have differnet infrustr for qm/asil clients -> to have the FFI (qm is too slow)
    • is done by cofiguration
  • problem: ifuse notification handler it is resource heavy in comparison with the polling
  • proc for mw::com
    • status notificytion
    • HYP setup
  • diag might be done as asilb for events
  • need to ping mw::com guas for the details about overhead and details, actual mechanisms
• Verificsation
  • @BlueXMarv3l prepared the first API test. video is presented with fake slave and demo app using the API change on QNX
  • Current demonstration environment: steady_clock -> fake_time_slave -> /dev/shmem/gptp_ptp_info -> demo_time_daemon -> SVT SHM -> demo_app
  • end-to-end test
    • IEEE 802.1AS Network -> TimeSlave -> /dev/shmem/gptp_ptp_info -> time_daemon(*) -> SVT SHM -> app
    • HW need to be setup, might be done till next time
    • hw timestamping will be used
• Linux support
  • @BjoernAtBosch opened a new pr to support the ticket: Fixes/improvements to let the whole chain run under Linux (Ubuntu 24.04 within WSL2): Fixes and improvements for Linux time#25 -> @lavrovvalera need to look
  • @lavrovvalera support from backlog
• TimeSlave folder structure support
  • the PR is prepared: Improvement:Update the timeslave to comply to SCORE conventions and add full-chain demo time#28 -> to review
• API discussion
  • Absolute time -> Global Time (?)
  • std::chrono wrappers
    • steady is mapped to CLOCK_MONOTONIC
    • system is appedto the CLOCK_REALTIME
    • wrappers shall stay
  • system ecarx
    • use case: system is used gps to sync to.
    • from score/time use case its ok to have the wrapper which most probably will not be used by ECAR
    • the std::crono:.system time (CLOCK_REALTIME) shall be synchronized to GPS in general -> to discuss i nthe scope of AbsTime/GloablTime/SDAt time

[lavrovvalera]

Weekly 2026-05-29

Participants

@lavrovvalera
@BjoernAtBosch
@florianfueller
@gordon9901
@BlueXMarv3l

MoMs

• Backlog
  • need to add the epic about mw::com discussion -> @lavrovvalera : Prepare the design decision page to use mw::come time#51
  • New topics added
  • request to everyone use the github way of linking PR to tassk, see https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue
• mw::com
  • 29.05: Now updates from BMW side due to to the vacactions
  • all comments are put to the Prepare the design decision page to use mw::come time#51 (comment)
• Needed reviews
  • Linux support: Fixes and improvements for Linux time#25
  • TimeSlave folder structure support: Improvement:Update the timeslave to comply to SCORE conventions and add full-chain demo time#28
    • shall we rename binaries as well?
    • Comments, which are not related to the folder update could be shifted to the seperated task/pr, that the flder structure updates are more atomically made. @BlueXMarv3l to create a task and link there all needed action items.
  • API change: Prepare the new score::time API time#18
• API discussion
  • High resolution -> hirs (HighresolutionSteadyTime)
    • as long as on Linux it might be not guaranteed to have the stead + high res: to focus steady + high_res, for qnx - implementd by ClockCycles, for linux - its an opened point. @lavrovvalera to create a ticket, hwo hirs could be supported on a guranteed level on Linux.
  • the rest APIs are stay as they are.
  • status flags
    • the definitions and use cases must be properly described on requirements and in the API
    • the IsSynchronized() function should be renamed to reflect the actual status
• Verification
  • ITF framework https://github.com/eclipse-score/itf
  • hw test:
    • 8xx linux hot - simulaiton,
    • arm qnx board
    • in qnx Timeslave, TimeDaemon, and demo app was used
    • synchronization happend
    • the sw timestamping was used
    • pdelay was jumping from ~20 usec to ~300 msec
    • switch was in between -> transparent clock
    • next step -> to enable hw timestamping

[lavrovvalera]

Weekly 2026-06-12

Participants

@lavrovvalera
@BjoernAtBosch
@florianfueller
@gordon9901
@BlueXMarv3l

MoMs

• Backlog
  • the priority is set, main ones are desctributed
  • Verification epic is assigned to @BlueXMarv3l
  • @lavrovvalera and @florianfueller to pick
    • requriements
    • API
    • mw::com decisions
    • need to bring the plannign for next score::release from https://eclipse-score.github.io/reference_integration/main/s_core_v_1/roadmap/roadmap.html

[lavrovvalera]

Weekly 2026-06-19

Participants

@lavrovvalera
@BjoernAtBosch
@florianfueller

MoMs

• time API change
  • Prepare the new score::time API time#18
  • Need finalize the review
  • the changes are done
  • the Init() funciton discussing is pending: move it to he seperated ticket
• score release 0.8
• the roadmap https://eclipse-score.github.io/reference_integration/main/s_core_v_1/roadmap/roadmap.html
• we could participate
• API
• system reqs
• quality stuff
• @lavrovvalera collect the tickets to the Product incremenet
• availability
  • @BjoernAtBosch realistic to say is off from 22.06 till begining of August with small availibility in between
• Udpted from @BlueXMarv3l
  • Replace mmap-based IPC with score_baselibs SharedMemoryFactory in ts_client — Targeting to finish the review this week.
  • Improvement: Feature Verification— Epic breakdown is done.

[lavrovvalera]

Weekly 2026-06-26

Participants

@lavrovvalera
@BjoernAtBosch
@pawelrutkaq
@florianfueller
@gordon9901
@indramaniarorascore
Sonu
@BlueXMarv3l

MoMs

• time API change
  • the ticket about Initialize procedure is created: Claify and fix the initialization procedure time#104
  • PR to review: Prepare the new score::time API time#18
• score release 0.8
  • the roadmap https://eclipse-score.github.io/reference_integration/main/s_core_v_1/roadmap/roadmap.html
  • release planning (draft) Prepare the roadmap for v0.8-v1.0 time#100
  • the docu: https://eclipse-score.github.io/inc_time/pr-100/release/roadmap.html
  • Actually we need to be prepard 2 weeks in advance to the refernce integrtion.
  • Could be decided on Monday tehc Sync work
  • regarding the refernece integrtion we could ping @pawelrutkaq
• CI workflows
  • Refactor the CI workflows time#102

[lavrovvalera]

Weekly 2026-07-03

Participants

@lavrovvalera
@pawelrutkaq
@florianfueller

MoMs

• time API change
  • the ticket about Initialize procedure is created: Claify and fix the initialization procedure time#104
  • PR is merged
• score release 0.8
  • the time is now present in reference integration repo
  • there are some issues in runnign TimeSlav and Time Daemon in the ref integration - > needs to have the configuration for both daemon. -> needs to be discussed with more people in
• CI workflows needs the review
  • Refactor the CI workflows time#102

[lavrovvalera]

Weekly 2026-07-10

Participants

@gordon9901
@BlueXMarv3l
@NEOatNHNG
@BjoernAtBosch
@FScholPer

Agenda

• CI workflows: current state
• docs - Module architecture structure: docs: decide feature granularity and folder structure for inc_time module time#121
• Time Slave and Time Daemon configuration. Running on reference integration repo
• score release 0.8

MoMs

• Tracy states that PR for integration tests is ready for review: Add initial platform management plan structure #122
• QNX build workflows working now (PR Bug: contribution guidelines contradict git guidelines #119)
  • To trigger QNX build you can add label test-qnx to the PR
• docs - Module architecture structure: Participants vote for option B
• Please review roadmap -> @ALL
• Enable Renovate for time module -> @FScholPer
• Discussion of ASIL requiremnts PR: [TIME] Add ASIL related requirements and rework existing #3020

[lavrovvalera]

Weekly 2026-07-24

Participants

@lavrovvalera
@gordon9901
@BlueXMarv3l
@Schulma
@NEOatNHNG
@florianfueller

Agenda

CI workflows: current state

• Feat: Add pre-commit, on-pr workflow & cr_checker time#138 -> precommit hook which needs to be merged
• CodeQL : need t o create a feedback loop + monitoring the results, when the workflow will be established -> to keep eye and fix issues before the release. @lavrovvalera to add the docs how to run iut locally

Roamap

• Prepare the roadmap for v0.8-v1.0 time#100 needs to be reviewed.

TimeSlave

• add the configuration to run the process on qnx. comm could be taken as example. woudl be good to have the cfg example, json schema, and the docs, exaplaining it. -> @BlueXMarv3l

Integration test

• pr is waiting for a review: feat: add TimeDaemon CIT with pip hub infrastructure time#122 needs to be reviewed till 31.07. It will release the next PRs for integration tests.

Feature requirements

• We need to prepare for the discussion for feature reqs. from ASIL poc, see [TIME] Add ASIL related requirements and rework existing #3020, Plan to have a bigger discussion on the 7th of August.

Backlog

• Reqs and quality KPIs needs to be slowly closed. TimeSlave -> @BlueXMarv3l , @lavrovvalera -> time.

Release

• @lavrovvalera clean the 0.8

New funcitonality

• @lavrovvalera needs to prepare the draft veriosn of the TimeDaemon configuraiton

Needs Review

• Add user manuals for time module time#133

[lavrovvalera]

Weekly 2026-07-31

Participants

@lavrovvalera
@pawelrutkaq
@florianfueller
@gordon9901
@Schulma
@BlueXMarv3l

Agenda

• TimeSlave configuration
• Roadmap (Prepare the roadmap for v0.8-v1.0 time#100)

MoMs

• TimeSlave configuration: @BlueXMarv3l is working on it. next week (07.08) possible delivery.
• Roadmap
  • Need to concentrate on Feature reqs
  • Need also not to forget the implementation
  • Till next meeting (07th of August the Team shall review the roadmap, that we could agree on high level destribution of the tasks) Prepare the roadmap for v0.8-v1.0 time#100

Needs Review

• Add user manuals for time module time#133
• Feat: Add pre-commit, on-pr workflow & cr_checker time#138 -> precommit hook which needs to be merged
• Prepare the roadmap for v0.8-v1.0 time#100 -> roadmap
• feat: add TimeDaemon CIT with pip hub infrastructure time#122 -> the integration tests
• [TIME] Add ASIL related requirements and rework existing #3020 -> Feature reqs

[lavrovvalera]

Weekly 2026-08-07

Participants

@NEOatNHNG
@BjoernAtBosch
@pawelrutkaq
@gordon9901
@BlueXMarv3l
@lavrovvalera

Agenda

• Feature reqs discussion (based on [TIME] Add ASIL related requirements and rework existing #3020)
• Need a strategy to merge the PRs
• Precommit hook

MoMs

• ASILB/QM reqs
  • we can add the stekholder req, that module shall support the ASIL-B apss
  • we can put the asil-b directly to some of the stackholder reqs
  • we definitely need the API to be asil-b, but if the timestamp data shall be asil-b or qm is enough -> its the open question.it can't be answered from s-core, that means the module shall be prepared to provide the possibility to qualify the data in asil-b manner. That menas the TimeDaemon must be asil-b as well.
  • Summary: we can maekr API reqs as ASIL-B and need to add requereemnt about qualification extention
  • Synchronize the HW clock with Vehicle Time
    • is it a stakeholder or feature reqs
    • we might need reformulations: which clock is ment and so on. which is the expected behaiviout which is visible outside.
    • @lavrovvalera t oclarify the points
• Need a strategy to merge the PRs
• Main problem would be the review of the PRs
• Proposal: to add the PRs for a reviwe in MoMs, and put to the Slack with reminders
• Precommit hook Feat: Add pre-commit, on-pr workflow & cr_checker time#138
  • might be conflicting with some local branches, which will prevent the commit without clearnign the stuff -> very hard tro work with the draft PRs
  • create the small tooling who wil lexecute the "gate" stuff -> could be run manually. like the release check.
  • @lavrovvalera wil lreate a ticket for that (tooling)
  • in the tooling we need to conclude the way how it is doen in the precommit hook (license and something else check)
  • Decision: the Team is agains the pre commit hook.
• Roadmap
  • the duplication was there for the explicit review
  • @lavrovvalera needs to update it

Needs Review

[lavrovvalera]

Weekly 2026-08-14

Participants

@BjoernAtBosch
@NEOatNHNG
@pawelrutkaq
@gordon9901
Matthias Schulze
@BlueXMarv3l
@lavrovvalera

Agenda

• Feature reqs discussion (based on [TIME] Add ASIL related requirements and rework existing #3020)
• 0.9 + roadmap discussion
• review the PRs, what is urgent

MoMs

• ASIL-B/QM reqs
  • the asil-b solution could not be done e2e by score project, but we could guarantee the local verification as asil-b. then we need to have the assumed safety reqs and AoU which limitation do we have and what the integrator shall take on the top
  • TimeDameon as asil-b
    • load plugins might be a tricky one: plugin mechanism is not asil-b on QNX. We could prepare everything and configure in the elf file which dynamic libraries to use. Need to prepare the proposal of the static linkage, how could we finally provide the "building blocks" and build the final binary on the project side. @lavrovvalera will create a ticket for the proposal. -> @BjoernAtBosch + @NEOatNHNG. Should be put to the arch docs
    • the static approach (when the binary is prepared on project side and Time module provides just the static submodules and the projects cretaes the binary)
    • another approach will be to standardize the ipc between the TimeSlave and TimeDaemon, then the TimeDaemon will be not touched at customer project
    • Different time bases support inside the TimeDaemon
    • FFI or asil-b on API reqs:
      • Approach 1: have 1 API req + 1 FFi req
      • Approach 2: have 1 API req + 1 ASIL-b req
      • Approach 3: API req is asil-b + AoU how that could we used
    • In general we can have the comüponent which is ASIL-X, but it doesn't implemnet any safety requirement.
    • We can make the Vehicle API and the validation (as part of it) as asil b, then we can certify the local validation and api in combination with AoU towards project or user, who needs to make something on the top to make it indeed asil-b. Then we can make the stakeholder and feature req as Asil-b and follow the process. We can start with doing it on Vehicle Time and Os Times. The Abs time could stay as QM for the moment. FFI of the AbsTime will be guranteed by component integrity level as asil-b. @BjoernAtBosch + @NEOatNHNG to revisit the requirement to make this statement

[lavrovvalera]

Weekly 2026-08-21

Participants

@BjoernAtBosch
Matthias Schulze
@lavrovvalera

Agenda

• documentation restructure feature/component
• folder structure
• asil-b reqs followup (based on [TIME] Add ASIL related requirements and rework existing #3020)

MoMs

• documentation restructure feature/component
  • Feature architectrue shll be moved to module Update the Time Architecture #3200 @lavrovvalera t ocheck if we really need to move and the dexcription in the folder structure (https://github.com/eclipse-score/score/blob/main/docs/contribute/general/folder.rst) is up to date
  • if we need to move: i nthe module arhcitecture folder we need to combine the feature, see Update the Time Architecture #3200, but descirbe there actual sw components (high level), skip the sw component internal design. We rawly defined the responsibility, why they separated and so on
  • in the Sw comp: we prepare the detailed design and go as deep as it wouldmake sense to describe the desgin per component. Architecture design then could be skipped. If the Inspection or review will show, we need to split it to arch + dd, we can split it afterwards.
• asil-b reqs followup
  • we have several approaches
  • the api reqs could be maked as asil-b saying, the interface supported the FFIl only. then we need to have on stakeholder level the requirement, saying, we need to have the data, provided by the some interfaces, with the integraty. then we could have the feature requirements as asil-b and proivde the AoU howto make this eintagrity
  • other way - just to combine: if the feature and stakeholder reqs as marked as asil-b, trhat measn FFI + data integrity -> AoU for that.
  • marked everyhgin as QM
  • monotnic time/hrsc use case:
    • we can provide the asil-b wrapper around the hw or os mechianism, whic hwill say, we are not midfing (or jsut converting) the data. but to make it ASIL-B form data perspective, we needto have the AoU towards HW/OS, theat the mechanism behind must be asilb and sutisfy its own hw requirements. To do so we need to have the dedicated stakeholder reqs. We need to have the AoU, that the fucntion, which we are calling must be asil-B then, and then we can guarantee, that score::tiem provide it also with the asil-b integrity

[lavrovvalera]

Weekly 2026-08-28

Participants

@BjoernAtBosch
@gordon9901
@BlueXMarv3l
Maciej Salwa
@pawelrutkaq

Agenda

• v0.9 checklist [time] Release v0.9 checklist time#190
• asil-b reqs followup (based on [TIME] Add ASIL related requirements and rework existing #3020
• Merge strategy for the module @NEOatNHNG
• reviews

MoMs

• v0.9 checklist
  • Unclear what needs to be done here
• asil-b reqs followup
  • All comments fixed, waiting for feedback of Valery regarding the meaning of ASIL_B rating in API requirements
• reviews:
  • Many PRs merged/closed this week
  • Open PRs of @gordon9901:
    • feat: add QNX process configuration, schema, docs for TimeSlave reference Integration time#158 - @BjoernAtBosch: Will re-review today
    • feat: add TimeDaemon CIT with pip hub infrastructure time#122 - Some discussion needed
  • Other open PRs are about documentation (adding doxygen) and component requirements - can be reviewed

[lavrovvalera]

Weekly 2026-09-03

Participants

@florianfueller
Maciej Salwa
@BlueXMarv3l
@gordon9901
@BjoernAtBosch
@lavrovvalera
@NEOatNHNG
@pawelrutkaq

Agenda

• v0.9 checklist [time] Release v0.9 checklist time#190
• Release 0.0.2 created
• asil-b reqs followup (based on [TIME] Add ASIL related requirements and rework existing #3020
• reviews
• merge queues

MoMs

• v0.9 checklist

  • jsut for INFO

• Release 0.0.2 created

  • the 0.0.2 willbe part of 0.9
  • Next release could be done based on our decisions

• asil-b reqs followup

  • one possibility is to have the tiem sync as qm + ffi towards memory
  • athe argument against is we could still have the asil-b on requirements. that we could prequalified on score side but still it will be not enough
  • if we will put asil-b on requirements, will it mean the asil-b on the all intenal stuff including the data or not. Then we could stay with 1 requiremnt, that we are providing the data with integrity: "we are sure, what we are providing"
  • Proposal to merge the [TIME] Add ASIL related requirements and rework existing #3020 hwo it is now and improve it further after FMEA and FTA done

• merge queues

  • for most of the PRs we can use jsut "squash and merge"
  • but after it, we can't merge other PR straight a way. we need t owait until rebase + untile all CI jobs will be done
  • that can be solved with merge queues -> multiple PRs merge will be easier
  • it will rebase on the latest main and execute the workflows
  • in case of failure it will remove from the queue
  • Approved from the Team, @NEOatNHNG will create change for that

• reviews:

  • sw comp reqs
    • Add time slave component requirements time#151
    • feat: Quality pack targets time#150
    • add time_daemon component requirements time#153
    • Add ts client component requirements time#149
  • feat docu
    • Update the Feature design time#188
  • doxygen docu
    • migrate time_slave detailed design to doxygen time#193
    • migrate time_daemon detailed design to doxygen time#194
    • migrate time lib detailed design to doxygen time#195
    • Migrate ts client detailed design to doxygen time#201

[lavrovvalera]

Weekly 2026-09-11

Participants

Agenda

• v0.9 PI tickets is closed. all tickets are moved to 0.10
• Callbacks API @florianfueller

MoMs

• v0.9 PI ticket Time for S-CORE Release v0.9 #3011 is closed. All not closed tickets are moved to Time for S-CORE Release v0.10 #3013

Reviews:

[lavrovvalera]

Weekly 2026-09-18

Participants

@florianfueller
@gordon9901
@MaciejSalwa543
@BlueXMarv3l
@lavrovvalera
@BjoernAtBosch

Agenda

• Callbacks API @florianfueller
• Reworked Stakeholder & Feture reqs: Update the Time Architecture #3200 @lavrovvalera

MoMs

• Callbacks API
  • mw::com fo SD has the long running thread in the pool
  • possible solution: Lazy thread initializaiton and not stopping thread afte the last clalback unregister to support the use case for re-register the callback back
  • in case of no callbacks are registerd any more, we could have the CV to wait until the newxt callback registration or join the thread
  • the proposed solution sounds ok.
• Reworked Stakeholder & Feture reqs
  • the stakeholder might need to specify more detailes that it is done on the change. Like what exactly is needed from stakeholder pov.
  • also the stakeholder req level should provide the expectation of the asil level. here we currently have a blocker, that if they will be ASIL-B we can't link to the QM reqs.
  • To cross check: if there should be a link from score docs t omodule docs about the arhcitecture description -> @lavrovvalera

Reviews:

[lavrovvalera]

Weekly 2026-09-25

Participants

@lavrovvalera
@BjoernAtBosch
@MaciejSalwa543
Matthias Schulze
@florianfueller

Agenda

• Reworked Stakeholder & Feture reqs: Update the Time Architecture #3200 @lavrovvalera
• SW Comp reqs review
• Later asil qualification open points

MoMs

• Reworked Stakeholder & Feture reqs
  • From 26-09-18:
    • the stakeholder might need to specify more detailes that it is done on the change. Like what exactly is needed from stakeholder pov.
    • also the stakeholder req level should provide the expectation of the asil level. here we currently have a blocker, that if they will be ASIL-B we can't link to the QM reqs.
    • To cross check: if there should be a link from score docs t omodule docs about the arhcitecture description -> @lavrovvalera
  • Today:
    • Agree not to have additional details on the stakeholder level.
    • Proposal by @BjoernAtBosch was to add some details on feature.
    • Proposal: @lavrovvalera update the PR with the latest updates and prpare for the review.
• SW Comp reqs
  • Call for a review

• Later asil qualification open points

Reviews:

[lavrovvalera]

Weekly 2026-10-02

Participants

@lavrovvalera
@MaciejSalwa543
@florianfueller
Matthias Schulze
@BjoernAtBosch

Agenda

• TimeDaemon integration topic

MoMs

• Callback impl is almost ready
• Requirements status: in progress, next week is expectations to have the PR
• TimeDaemon integration strategy: @MaciejSalwa543 and @lavrovvalera to prepare the proposal. @lavrovvalera to find a ticket for that.
• Verification
  • Need to wait for the feedback from @BlueXMarv3l about current status
  • At the moment wer are lacking the systematic startegy, how are we planning to test (mainly on integration level)
  • we could start also wit hthe low-expectation precision smoke tests
  • there is also an idea to fix the pdelay measuments on the TimeSlave side.
• @lavrovvalera wil lcleant up the v0.10 planning. -> for 09.10 plan to the 0.10 planning topic
• TimeDaemon configuration: we need to have the possibility to configure the thresholds. @lavrovvalera create a ticket.
  • One ofthe ideas is to have the common config fiel for TimeSlave and TimeDaemon, the blocker could be - on the project side different TimeSlave process mght be used, then TimeDaemon will be aware about the dead options in the config.
  • That idea could be reused n a way: the integrator has the "common" feature config, and the final configuration (jsons or whatever) will be generated during build time: one for TimeDaemon, another for TimeSlave.

Reviews:

• We need to review the SW Comp reqs @lavrovvalera and anybody

[lavrovvalera]

Weekly 2026-10-09

Participants

1. @florianfueller
2. @MaciejSalwa543
3. @NEOatNHNG
4. @lavrovvalera
5. @BjoernAtBosch
6. @pawelrutkaq

Agenda

• Callbacks implementation + TimeDaemon::Ipc
• Tickets linkages
• Reviews and approvals missing
• Open tickets

MoMs

• Callbacks
  • implementation is almost done.
  • new unit test fro shmemhandler is created
  • the issue with the race in current implementation found and fixed
  • two atomics shall be refactored to use one atomic or to double buffering or to pache to one atomic status, index, somthing.
  • what is the proposal:
    • have 1 atomic counter (odd/even)
    • make 2 buffers. need a bit mor thoughs - differnet cache lines and so on
    • Proposal: currently to go with the easiest solution for the moment
• Tickets linkages
• Commiter
  • @NEOatNHNG is the commiter, but doesn't have much tiem for a review. Pattern: one +1 -> could be merged
  • the proposal to make more commiters is ongoing.
  • we need to make the reviews more often.

Reviews:

[lavrovvalera]

Weekly 2026-10-16

Participants

1. @BjoernAtBosch
2. @florianfueller
3. @gordon9901
4. @MaciejSalwa543
5. Matthias Schulze
6. @BlueXMarv3l
7. @lavrovvalera

Agenda

• Commiter list

MoMs

• Commiters
  • @NEOatNHNG -> Michael Tänzer
  • Commiters list https://projects.eclipse.org/projects/automotive.score/who#:~:text=Thilo%20Schmitt-,Committers,-Nils%20Hoppe
• Callback implementation is merged.
• the TimeDaemon integration to a vendor specific project strategy is ongoing. Possibly might be ready for a presentation nextweek
• @BjoernAtBosch create a ticket to cross check, if we need to extend the data passng from the TimeSlave towards TimeDaemon. the scope - safe and non safe data validation
• the merge queue is a benfitial -> @lavrovvalera to cretae a ticket to implement it. would be also a benfitial for commiters to merge the change
• Integration verificaiton
  • update status offline
• SW reqs review. some comments were done after the merge. Propose: to finish the feature resq and then come back to SW reqs.
  @lavrovvalera -> cretae a ticket and move to different PI.
• Ubuntu 26
  • @lavrovvalera create a ticket to check the migration to ubuntu 26.
  • how could we centralize? could we have the central way of configuring it within the module?
  • or it will be easier just to have the latest-gratest?
  • alway have the lates-greates could lead to some non expected issues
• @lavrovvalera cretae a ticket to create the verification reports via spinx needs, that he module iwll be included to the main generted report on the integration repo side.
  • Idea. to have the module-speicif board or geenrated documentaiton with the current KPIs: requirs coverage, code coverge and s oson. @lavrovvalera create a ticket for that. Specify the exact list of the wanted KPIs to be shown.
    • How to stroe it for releases? Will the refernce integrtio nsolve that ehtn? WE eed have the dedicated workflow + report generated for the Module release + store all artifacts in a persistent manner -> We need to define the release process for the module. @lavrovvalera to check the existing ticket and to create the new if needed.
    • we could see the other modules as an example. also here https://docs.conan.io/2.20/index.html the versions will docuemntation could be switched.
  • @BjoernAtBosch will be off next week, availabel back from 26th of October.

Reviews:

[gordon9901]

Integration Test Status Update

• PR1 (TimeDaemon CIT): Submitted (#122). Major review comments have been addressed. Test implementation was adjusted to use gtest for component-level integration, while retaining Python infrastructure for future process-level tests. Pending final review and merge.
• PR2 (TimeSlave CIT): Branch prepared, pending PR submission. Will align with the updated PR1 testing approach.
• PR3 (TimeSlave ↔ TimeDaemon MIT): Branch prepared, pending PR submission. Planned to use score_itf for cross-process integration testing.

Next Steps: Prioritize PR1 review and merge, then proceed with PR2–PR3 submissions and reviews based on the confirmed testing strategy.

[lavrovvalera]

Weekly 2026-10-23

Participants

1. @florianfueller
2. Matthias Schulze
3. @NEOatNHNG
4. @MaciejSalwa543
5. @BlueXMarv3l
6. @lavrovvalera

Agenda

• TimeDaemon project integration
• Merge queue

MoMs

• TimeDaemon project integration
  • In oder to be able to integrate th TD to the project we need to "open" the TD subcomponenets nd make them publec, then they could be assembled byck on the project side
  • Move the common lifecycled code to GerenericTimebaseHandler, the SVTHandler (or any other Handler) will jsut create and wire the compoennts
  • Allow TD to run multiple handlers through a common factory
  • PR is ready for review Add a generic timebase handler to TimeDaemon time#244
• Merge queue
  • ci: Prepare merge queue validation for Time time#261 & Enable merge queue for Time .eclipsefdn#242
• Fix for data race in TD:ipc
  • In draft
  • only 2 slots will simplify the algorithm
  • each slot shall have the same seq lock inside in oder to give the possibility to reader to detect the data race and reread
  • writer shall never be blocked or retry to wait for reader (reader could be QM and just block the slot)
  • soem overhaead with cache line modificatons

Reviews: