From 3326e836e8f2a6acdec401fe35fe97b2a7d1a29e Mon Sep 17 00:00:00 2001
From: Ben Franksen <ben.franksen@online.de>
Date: Wed, 28 Mar 2012 19:49:18 +0000
Subject: [PATCH] docs: extended safe mode explanation with a remark on
priorities
---
documentation/Reference.txt | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/documentation/Reference.txt b/documentation/Reference.txt
index 10dd5b51..d2f192ef 100644
--- a/documentation/Reference.txt
+++ b/documentation/Reference.txt
@@ -1650,7 +1650,7 @@ traditional unsafe mode.
In the traditional (unsafe) mode, variables are *not* protected against
access from concurrently running threads. Concurrent access to SNL
variables was introduced in version 2.0, when implementation of the PV
-layer switched from the traditional single threaded CA mode ("preemptive
+layer switched from the old single threaded CA mode ("preemptive
callbacks disabled") to the multi-threaded mode ("preemptive callbacks
enabled") in order to support more than one state set per program. This
could result in data corruption for variables that are not read and written
@@ -1672,6 +1672,19 @@ While it is possible to avoid the first case by careful coding (using e.g.
event flags for synchronization) it is not possible to guard against the
second case as these events can interrupt action statements at any time.
+One of the reasons SNL programs have mostly worked in spite of this is
+that due to the standard CA thread priorities the callback thread does not
+interrupt the state set threads. Furthermore (and contrary to what many
+people believe) the VxWorks scheduler does not normally serve threads with
+equal priority in a round-robin (time-sliced) fashion; instead each thread
+keeps running until it gets interrupted by a higher priority thread or
+until it blocks on a semaphore.
+
+However, thread priorities are not honored if programs are run under
+Linux or Windows in user mode; and anyway, priorities should only be used
+to improve latency for certain operations (at the cost of others) and
+*never* should they be relied upon for program correctness.
+
Safe mode solves all these problems by changing the way variables,
particularly global variables, are interpreted. In safe mode, all variables
--except event flags-- are interpreted as if they were *local to the state
--
GitLab