Sorry I can't relate to your example. The way we did things, all variables that needed to be 'touched' by two tasks went via OS specific shared virtual memory queues with built in hardware locking. Later generations on a different hardware platform had software locking that we had to manipulate.
All our tasks when started built an in memory list of variables MOSTLY not shared but if they were, the rule was all other tasks could only read. We were ready to implement a locking method to allow multiple writers but in 10 years never found a reason to do so.
I should explain that we did have the abiity to add data (like a com port) via a supervisory task that our operators were trained in BUT the code added the new data to the doubly linked list before connecting the new element to the list and sending a signal to the reader task.
I guess what I am saying perhaps in a poor way is that my design was different from yours and did not have your problems.
Remember, in my system, no memory in the task was exposed to other tasks, all shared variables were in shared memory outside the compile unit. We had a root pointer that had to be put in the link edit step of every process that provided a starting point to the doubly linked list that every task if needed had to use.
I hope I explained that well enough.