Questions about random numbers in deterministic execution

[luckeyhy]

Sorry to bother you, but combined with the standard and your open source, I can't figure it out, I hope you can help answer, thank you very much!
1、Where does the random number assigned by GetRandom API to the workers in the worker pool come from? I see that the function you wrote is to directly obtain the random number of each cycle in the DeterministicClient instance, I think it should not be the case.
2、How does the deterministic random number assigned to container elements in the second paragraph achieve deterministic execution? Why assign random numbers to container elements and workers at the same time? Or is it that the random number assigned to container elements is obtained by workers performing the task.
3、The standard is very general. I would like to ask how to achieve deterministic execution of random numbers, including allocation to workers and container elements. Can this achieve deterministic execution?

[langroodi]

It is unclear for me what you are exactly struggling with, but I try to answer your questions (and the questions within those questions) based on my understanding.

1.1- As far as I know, the standard does not specify the source of the random number. So, it can be a regular pseudo random number generator as long as it matches the safety/security requirement of the component you are designing.

1.2- I do not see any reason why it should not be the case (if I understand your point correctly). Deterministic client should guarantee that the random number stays the same in a specific cycle while calling GetRandom on any instances and the current implementation actually does that (please refer to DeterministicClientTest). However, in a real-world scenario, it is the responsibility of DeterministicSyncMasterto synchronize the time stamp and the random number generator seed (not the random number itself) within different deterministic clients. But still deterministic clients need to provide that random number because they are the one who are exposing that API.

2.1- It is not specified in the standard how you need to assign random numbers to the elements in the container. As long as all the elements are waiting for the same activation cycle, they need to receive a same random number (if they need actually a random number for their processing). The only requirement here is that the container provides an iterator for the assignment.

2.2- No, it is not at the same time; you've already answered that:

It is it that the random number assigned to container elements is obtained by workers performing the task.

3.1- That section of the standard IS NOT about how to achieve deterministic execution of random numbers but it IS about how to generate random numbers to achieve deterministic execution. So, for that you still can refer to the current implementation within the project.

3.2- Of course not. The idea of the deterministic client is to HELP us to achieve deterministic execution by providing us some tools (e.g., random number, time stamp, worker, etc.) via its API. However, we still can violate deterministic execution in our tasks assigned to the workers.

[luckeyhy]

First of all, I am very happy to receive your detailed reply.
According to my understanding, there are two levels of random numbers: process running cycle level (a kRunning cycle corresponds to a random number) and worker level (when running in the worker thread pool, run with an iterator and each run corresponds to a Random number, in addition, the random number should be the same when running in parallel).

[langroodi]

I am not sure if such a categorizing you described is aligned with the standard, but the last time I read document, I did not have the same impression (but still I can not deny your understanding).
By taking a look to the following figure, workers from the pool can be executed while the process is in the kRunning state, and in that case all the workers (even they are initialized via a container) till the next activation time will get the same random number:

So, the two levels you mentioned not fit the context IMHO. While workers or the process are executing in the current cycle, they will get the same random number (regardless they were a worker or the process itself).

[luckeyhy]

So how is the deterministic worker thread pool implemented?

• Your function (ara::exec::DeterministicClient::GetRandom()) directly obtains the random number of each activation cycle of the process, not to distribute random numbers to the worker threads in the thread pool as mentioned in the standard.

[langroodi]

First of all, I cannot guarantee that what I've implemented is correct. It has been implemented based on my understanding which can be wrong. mRandomNumber is a static variable. It means all the instances of deterministic client will access only one mRandomNumber. So, if you look at this function, at each cycle activation a new random number will be generated and assigned to mRandomNumber. So, while calling GetRandom always a same random number will be returned till the next cycle.

Regarding your post of SWS-EM-02225, the GetRandom signature implemented here is based on the standard. How it can distribute a random number among workers without having references to the workers?! It is the responsibility of the process to distribute the random number provided by the client and not the client itself (at least from my understanding and the image I've posted in my previous response).