Changeset 1126 in webkit for trunk/JavaScriptCore/kjs/value.h

Timestamp:

May 10, 2002, 9:41:01 AM (23 years ago)

Author:

mjs

Message:

Reviewed by: Ken Kocienda and Darin Adler

Fixed the following bug:

Radar 2890573 - JavaScriptCore needs to be thread-safe

Actually this is only a weak form of thread-safety - you can safely
use different interpreters from different threads at the same
time. If you try to use a single interpreter object from multiple
threads, you need to provide your own locking.

• kjs/collector.h, kjs/collector.cpp: (Collector::lock, Collector::unlock): Trivial implementation of a recursive mutex. (Collector::allocate): Lock around the body of this function. (Collector::collect): Likewise. (Collector::finalCheck): Likewise. (Collector::numInterpreters): Likewise. (Collector::numGCNotAllowedObjects): Likewise. (Collector::numReferencedObjects): Likewise.
• kjs/internal.cpp: (Parser::parse): use a mutex to lock around the whole parse, since it uses a bunch of global state. (InterpreterImp::InterpreterImp): Grab the Collector lock here, both the mutually exclude calls to the body of this function, and to protect the s_hook static member which the collector pokes at. (InterpreterImp::clear): Likewise.
• kjs/ustring.cpp: (statBufferKeyCleanup, statBufferKeyInit, UString::ascii): Convert use of static variable
• kjs/value.cpp: (ValueImp::ValueImp, ValueImp::mark, ValueImp::marked, ValueImp::setGcAllowed): Grab the GC lock around any flag changes.

File:

• trunk/JavaScriptCore/kjs/value.h (modified) (1 diff)

trunk/JavaScriptCore/kjs/value.h

@@ -95 +95 @@
     virtual ~ValueImp();
 
+#ifdef APPLE_CHANGES
+    // The collecter lock is not locked around the ref() and unref()
+    // methods for the following reasons:
+    //
+    // - The only cases where chaging the refcount could possibly
+    // affect the collector's behavior is incrementing from 0 to 1,
+    // and decrementing from 1 to 0.
+    //
+    // - In the 0 to 1 case, the GC allowed flag will always be off
+    // beforehand, and set right afterwards. And setting it grabs the
+    // collector lock. So if this happens in the middle of GC, the
+    // collector will see either a refcount 0 GC not allowed object,
+    // or a refcount 1 GC not allowed object, and these cases are
+    // treated exactly the same.
+    //
+    // - In the 1 to 0 case, the only possible bad effect is that the
+    // object will live for one GC cycle longer than it should have
+    // to, which is really not so bad.
+    //
+    // - In theory on some platforms increment or decrement could make
+    // other threads see intermediate values that are different from
+    // both the start and end value. If that turns out to really be
+    // the case we will have to reconsider this scheme.
+#endif
     inline ValueImp* ref() { refcount++; return this; }
     inline bool deref() { return (!--refcount); }