I'm a stickler on this, and lots of things folks are sure are safe, I consider unsafe and will not write. For example,
1.) Initialize shared data, which will remain constant from here on out. 2.) Launch threads. 3.) Access shared data in one or more threads, assuming it was initialized. Lots of code is written like this, and works fine, but I consider the above unsafe. Why? There is no guarantee that the memory the threads see in step 3 has yet been initialized by Step 1. This becomes safe if don't have threading on at all during step 1, and you add a step 1.5) Turn on threading. because turning on threading will assure that memory is synced as of that point. This also becomes safe if the initialization is in the executable -- not done at run-time. On Sun, Dec 7, 2014 at 11:21 AM, Jeffrey Kegler < [email protected]> wrote: > It might help to build on your idea. As you note, there are no global > mutated values, and that means Marpa is thread-safe, in the sense if you > are running several completely independent instances of Marpa at once, > there will no problem -- the only data they share is constant. > > However, if you, for example, create two recces from the same base > grammar, both recces will share non-constant data in the grammar. (There's > no logical necessity for this sharing, I just found it convenient.) So, > from the point of view of the two recce's the data in the base grammar is > "global". That is, as you checked (thank you for making sure, by the > way!) multiple Marpa instances won't share executable-wide non-constant > globals. But two recognizers *will* share what from their point of view > are non-constant "globals" in their shared grammar. And between these 2 > recognizers, all the same issues arise that would arise between two Marpa > instances that were sharing non-constant program wide data. > > The use of shared values in the grammar is not aggressive, but memory > coherence issues make any sharing of non-constant data between threads > dangerous. > > So this is why Marpa *is* thread-safe for multiple Marpa instances, but is > *not* thread safe for multiple recognizers (or other derived objects) based > on the same grammar. > > I hope this helps, jeffrey > > On Sun, Dec 7, 2014 at 11:04 AM, Vaše jméno <[email protected]> wrote: > >> jeffreykegler, sorry to come up with the threading thing again, but >> anyway: It's sure not an obstacle for libmarpa use. Im not looking to >> paralellize my parser either, i dont need to create multiple grammars, im >> planning to use a standalone process. >> >> I think, tho, it would be the simplest pattern of integrating libmarpa. >> First i had everything working in my apps main thread. Now that i >> realized parsing takes time, the simplest change would be to keep the code >> that sets the grammar up in the main thread, and do precompute and parse in >> another thread. >> >> It seems easier to just avoid touching the grammar from the main thread >> once the parsing thread is running, instead of creating a "special marpa >> thread", keeping it around, telling it to call my grammar defining >> function, then telling it to parse.. >> >> What doesnt let me drop this topic is that you have, again, not given a >> technical explanation, and i feel theres something i dont understand that i >> should:) >> >> The fact that time objects use their base grammar doesnt explain it in >> any way. Nor does the theory of atomicity touch upon, in any way, the >> sequential use in multiple threads. >> >> I tried a few greps on marpa.w, and all i could conclude was that i didnt >> see any funcion-local static variables. Am i loosing my c-skills? Is the >> reason in other libraries? >> >> In that you want to have the freedom to change this in future? >> Just curious. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "marpa parser" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "marpa parser" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
