On Wed, Dec 11, 2019 at 3:44 PM Michael Matz <matz....@frakked.de> wrote: > > Hi, > > On Wed, 11 Dec 2019, grischka wrote: > > > Couldn't help to try out some things, related to the matter. > > See > > https://repo.or.cz/tinycc.git/commitdiff/72729d8e360489416146d6d4fd6bc57c9c72c29b > > Yeah, something like that was in my mind as well. > > > Anyway I think, it still does look like tinycc. > > Indeed, nice, I like it! But let me disagree with parts of one comment > you added: > > + /* Here we enter the code section where we use the global variables for > + parsing and code generation (tccpp.c, tccgen.c, <target>-gen.c). > + Other threads need to wait until we're done. > + > + Alternatively we could of course pass TCCState *s1 everwhere > + except that it would look extremly ugly. > + > + Alternatively we could use thread local storage for those global > + variables, which may or may not have advantages */ > > The last alternative really isn't one. If you move some global variables > to be thread-local, you now have multiple potentially different copies. > Some TCCState state refers to the global (then thread-local) variables > (e.g. symbol table or string/token indices), so you'd have to associate > each TCCState with the specific instance of the thread-local to which it > wants to refer. Now you either have bound each TCCState to a specific > thread, or you need to introduce locking again because you might refer to > data from different threads, which thread-locality was supposed to avoid. > The only reason why the current scheme works is because there's only a > single copy of the global data. Having multiple copies (e.g. by > introducing thread-local) effectively means you have to move that data > into TCCState itself (at which point thread-local become moot again). > > > Ciao, > Michael. I'm pretty happy with the solution found so I wont complain but I'm not sure to understand the problem with Thread local storage. If I've understand correctly the problem happen only if you use a TCCState that has been allocated in another thread, is that right ? Is it really a problem ? (you can return an error if running from the wrong thread) Well in any case the semaphore seems a cleaner solution
Matthias, _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
