In reply to mseyunni:
I don’t see enough information here to answer your question.
Why do you have a fork-join with a single if-statement inside it?
If active_ids starts out empty, how is the if-condition ever satisfied?
It appears that you want to make sure that a) each msg_id is unique relative to other ids that are in-flight at the time the message is created, and b) you only want to assign/store msg_ids when the message is sent to the DUT.
If this is the case, then you could use the config_db to ensure that the driver sequence and monitor both have a handle to the same active_id queue. In the sequence, you can randomize the msg_id in between start_item() and finish_item(), and constrain it so that it is not inside active_ids, as you show in the constraint block in your drive_seq1() task. So, you’ll only be randomizing the msg_id when the transaction is about to be sent, so you don’t have to worry about pre-assigning ids. Then, you can use the monitor to recognize response transactions and delete the ids when you see them.