Subj : Re: Executing 2 scripts in parallel using the same global object To : Harizakis Costas From : Brendan Eich Date : Wed Jun 04 2003 10:51 am Harizakis Costas wrote: > I was wondering how can I execute 2 scripts in paraller (using 2 threads), > using the save global object. Why would you want to? > Given the following: > > - Create a native thread > - Initialize the runtime and associate it with a context. That's backwards: a context can be thought of as "in" a runtime, but you wouldn't associate a runtime with a context. You can't have one context in two runtimes; you can't move a context from one runtime to another (in general, you shouldn't need more than one runtime). > - Associate the context with a global object (initializing the common js > classes) That's backwards too: you mean associate a global object with the context. Objects do not exist in only one context -- they're in the runtime's GC heap. Contexts are per-thread state needed for concurrent execution. > - Declare some functions (as properties of the global object). > > Suppose that a new native thread is created, and wishes to execute one of > the globally -previously- declared functions; Which are the necessary steps > in order to do it safely using the thread-safe build of the js-engine? Use requests. > The JS_[Get|Set|Clear]ContextThread() functions as also the You don't need those unless you pool contexts and reassociate a context with different threads over its lifetime. > JS_[Begin|End]Request() do not clarify under which circumstances it is safe > to execute 2 scripts concurrently or if deadlocks may arise. Deadlocks are not the main problem, although GC/thread deadlocks are possible if the request model is not followed. Requests exist to organize execution into sequences of non-blockin activity on a context, with two aims: 1. Prevent the GC from running till all requests, or all but the request calling the GC, have ended or suspended. This is necessary because the JS GC is not yet concurrent or parallel (a bug to be fixed, some day). 2. Optimize object locking to use a lock-free technique for objects that can be determined to be accessible to only one context (thread). Such single-threaded objects can be accessed without more expensive interlocking of critical sections in the engine. If a single-threaded object becomes accessible to other threads, the other threads must wait till the request (if any) using the object has ended or suspended; after which the object becomes multi-thread-accessible, at the higher cost of MT locking. > Will the creation of a 2nd context for the 2nd thread allow me to > reference objects created on the 1st context? Yes. Does this imply that the > JS_[Begin|End]Request() calls may be omitted? No. > Example: > > - The 1st thread is executing a script. > - While in a native function a new thread is created (or an existing one > gets signalled) > - The new thread executes a pre-compiled script (same context). You cannot share one context between two threads in a concurrent or parallel fashion. You need a context per thread active at the same time. > - Both threads continue executing. Consider that the context contains the interpreter stack -- how can two threads use one LIFO list at the same time? > - The 1st thread completes and returns control to the user. > - User continue executing C code. > - The 2nd thread completes sometime later - any results are stored in the js > context. Why store results in a context? Store them in properties of objects. Once you have two threads and two contexts, however, you'll want two global objects. Otherwise the threads will race to get and set global variables, potentially colliding on common names. > > Is the above example realizable? No. > If yes which thread related JS_xxx() functions should be called and when? You need a context per thread that might be concurrently executing JS. The mention made above of pooling contexts and reassociating a context with several threads, each thread in turn, across the life of the context, does not violate this rule -- there is no concurrent (or SMP parallel) use of the context by more than one thread at a time. /be .