Changes between Version 45 and Version 46 of DjangoSpecifications/Core/Threading

Timestamp:

Apr 26, 2008, 3:50:37 PM (16 years ago)

Author:

mrts

Comment:

--

DjangoSpecifications/Core/Threading

@@ -16 +16 @@
 The main pattern of global variable usage in Django is ''use `var` if initialized, otherwise initialize''. This is generally not thread-safe.
 
-"Not thread-safe" has two broad subcategories:
- * inefficiencies due to initialization calls meant to occur only once occurring more than once (the general `if not foo: initialize foo`, including `memoize` decorator),
+"Not thread-safe" has two broad subcategories in this case:
+ * inefficiencies due to initialization calls meant to occur only once occurring more than once (including `memoize` decorator),
  * errors due to incomplete initialization.
 
@@ -25 +25 @@
  * locking would needlessly penalize single-threaded execution.
 
-Thus, lock-free algorithms should be always preferred and the inefficient case tolerated -- unless the inefficiency is highly probable and results in overhead that is considerably greater than with locking.
+Thus, lock-free algorithms should be always preferred and the inefficient case tolerated -- unless the inefficiency is highly probable and results in overhead that is considerably greater than with locking or has harmful side-effects.
 
 === Inefficiencies ===
 
-When evaluating the inefficiencies, their impact should be considered in terms of their probability and overhead of the duplicated call. The duplicated case,
+When evaluating the inefficiencies, their impact should be considered as outlined above: probability, overhead and side effects. The duplicated case,
 {{{
 1. thread 1: if not foo: true, needs initializing