[DGD] mp/tls fact check

Shentino shentino at gmail.com
Tue Nov 25 05:04:17 CET 2008


Don't mean to be nit picky, but...

First off, I think you should use the term "Execution Round" instead of thread.

Given that there are real threads behind the LPC horizon, using
"thread" could be ambiguous.



On Mon, Nov 24, 2008 at 1:52 PM, Chris <null.infinite at gmail.com> wrote:
> I began writing a help document for my lib describing some of the various things
> involved in optimizing code to be compatible with the upcoming DGD MP.
> I tried my best to put something sensible together, but i did not feel
> much confidence
> when i got to the part about TLS vars.
> If there is anything i wrote incorrectly, inadequetely, or anything
> important i left out, I
> would love to be corrected.  Here is the document in its current state:
>
>
> A thread is a single chain of code not broken up by call_outs, which originates
> from either a call_out or a user sending a message.
>
> There are three general rules which must be followed to preserve multi-threaded
> compatibility.  These rules are listed here below:
>
>  -There cannot be a private function prototype that is left undefined.
>
>  -If a call_other to a different object would change a global variable in that
>  object, and the best solution is not to use TLS vars (see below), than one
>  good option is to use a 'relay function'.  A relay function is a function with
>  a call_out (usually 0 seconds).  Once the function called with call_out
>  executes, it does so on its own thread, and is no longer breaking this rule.
>
>  -If more than one thread can compete to modify an external objects global
>  variable, than whenever these threads are executed simultaneous one of them
>  gets rescheduled.  When many threads are doing this, and rescheduling becomes
>  rampant, we have created a huge drain on DGD's ability to multi-thread.  To
>  avoid this we use TLS-vars.
>
>
> Thanks for input,
> -chris
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>



More information about the DGD mailing list