Bei der S4C+ wies ABB früher extra darauf hin, dass es eher nicht möglich sei, zyklische Hintergrundtasks ohne Wartezeit zu verwenden, weil sonst die Haupttask ins Hintertreffen geraten könnte. Selbst in SPS-Tasks mit Steueraufgaben habe ich dann auch später noch immer ein WaitTime 0.1 eingebaut, das reichte dann offiziell und auch aus der Erfahrung - in der Wartezeit erledigt der Computer dann die anderen Dinge.
Es gibt keine Gleichzeitigkeit. Du kannst nicht einmal sicher sein, dass ein Block von PERS oder auch EAs, der von einer Task beschrieben wird, sich nicht mitten im Schreibvorgang befindet, wenn die andere Task lesen will. Wer sich drauf verlässt, dass in einer Task zwei Programmzeilen hintereinander stattfinden, ohne dass eine andere Task zwischendurch stattfindet, wird mit sporadischen Fehlern der mysteriösen Klasse belohnt - je zeitlich enger, desto seltener, aber nicht "nie".
Bei nicht laufenden Motion-Tasks (also die, die erst über ein Startsignal gestartet werden), kommt noch irgendein Nachdenkvorgang vom System hinzu, insbesondere, wenn eines der beteiligten Module neu geladen wurde. Da bin ich auch schon allerübelst auf die Schnauze gefallen - das geht durchaus so weit, dass ein "WaitSyncTask" am Anfang nicht funktioniert, weil die Konkurrenztask noch gar nicht richtig läuft, mit der Folge, dass der Robbi, der warten sollte, durchmarschiert. (Jedenfalls war das mal bei bestimmten RW-Versionen so, weiß nicht, ob das immer noch so ist.)
Ich hab' mir jedenfalls angewöhnt, "Gleichzeitigkeit" zwischen Tasks oder auch zwischen Task und EA-System als "totally random" anzusehen und das beim Programmieren zu berücksichtigen.