Gordon, thanks for your answer. I think that you made an excellent point regarding putting objects with access methods in the conf db instead of a plain int for example.
What I do not get though is how the synchronous approach would remove a lot of non deterministic behavior, just like 2 clocked processes in a design that use blocking assignments to communicate are problematic.
In my uvm setup I have the following: I have 2 agents 1 and 2. Driver1 and driver2 are synchronous to the same clock. Sequence1 should react (decide on the next seq item content) to what happens in agent2. Suppose at a certain clock edge seq items in driver1 is finished, so sequence1 will have to make a new seq item. To decide on the seq item content (content A or B) it will look into the config db for the status in agent2. This status is set by sequence2 when it’s seq item was finished. Suppose this was in the same clock cycle and therefor the seq items in the 2 drivers finish in the same delta cycle.
When a simple shared state X is used I think the following 2 scheduling schemes can happen:
sequence1 checks for state X: X is not set, so a new seq item with content A is made.
sequence2 sets state X
Or
sequence2 sets state X
sequence1 checks for state X: X is set, so a new seq item with content B is made.