Przemyslaw and all involved, If I can say what I think, here it is: I'd like to have just one mode, the MT one, and just one set of extended api, the one we have now. Then, if I don't write .PRG level MT code I simply end up having all my code executed as thread #1.
This way GC can be on a different thread, terminals can update on-screen buffer asynchronously from .prg code and so on. It seems to me just a waste to have two sets of apis, two kinds of runtimes, two kinds of libraries and so on when the overhead is a mere 5%, that is, in a couple of months from now it will be removed by the use of faster cpus. Look at xbase++, they just have the threaded model and this is a plus since people start using it sooner or later if it does not require to rewrite things for MT, or use different libs, makefiles etc etc. With xHarbour it was decided to have two models MT and ST, and the end result is that only ST is really used/tested/rock solid and this was, for me, a _big_ mistake. Best regards. Maurilio. Przemyslaw Czerpak ha scritto: > > On Tue, 04 Dec 2007, Mindaugas Kavaliauskas wrote: > > I'm not the MT guru, but just have an idea. In current implementation we > > need access TLS for most of many Item and Extend API functions: > > hb_param(), hb_itemReturn(), hb_par*(), hb_ret*(), etc. The exception is > > some base Item API functions which does not access parameters and does > > not return value: hb_itemNew(), hb_itemGet*(), hb_itemSet*(). > > For example, if we have harbour level function implemented in C, and we > > need to access 5 parameters of the function and return a value, we'll > > need 6 times to get STACK pointer from TLS, because every hb_par*(), > > hb_ret*() is independent and needs STACK to do its job. > > What if extend Harbour API functions by set of MT "compatible" version > > of the functions? I.e. hb_mtpar*( HVM* pVM, int iParam, ... ), etc. > > HB_FUNC( AAA ) > > would be preprocessed to > > void HB_FUN_AAA( HVM* pVM ) > > And this is exactly what CLIP does. It passes to all functions > pointer to 'ClipMachine' structure which works like our HB_STACK. > Yesterday I read some xbase++ documentation (many thanks to all > of you who help me in locating xbase++ description) and XBASE++ > makes the same by they call it 'XppParamList'. Harbour has PHB_STACK. > These are only different names but the same functionality. > > > If function code uses old style hb_par*(), it will work OK, but it will > > be slower in MT mode. Number of hb_par*(), hb_ret*() and some hb_item*() > > functions is not very big, and writing MT version is easy > > (straight-forward passing of pVM to other API calls). > > Yes, it is easy but we will have to change calling convention for > existing functions and if we want to use the same libraries for > MT and ST mode then it will have to be global modification. > I like such API much more so you have my vote for this modification > but it will be problem for backward compatibility. Please also note > that we should try to force such modification in all code because > it will be valuable not only for MT mode but also for some other > situations. Even single thread program can use two or more HVMs. > If we want to keep old functions then we will have to chose naming > convention for the new ones. I think that we should respect commonly > used in POSIX functions _r sufix, f.e. hb_parc_r(), hb_retni_r(), ... > Please also note that to reduce TLS/TSD access in xHarbour HB_THREAD_STUB > is used. It helps when HB_STACK is accessed more then once in single > function. > But the most important for performance will be rewriting HVM functions > so pointer to HB_STACK will be passed to all hb_vm*() functions. Here > the performance we have highest performance overhead because HB_STACK > is accessed much more often then from C code. > Anyhow it's rather simple job which can be done later in spare time > when we will have MT support to improve performance and maybe merge > MT and ST VM library into single one. The most important will be > making other code MT safe, defining set of MT related functions > which can be used also in ST mode to avoid other library dividing > for ST and MT ones and decisions which resources should be thread > local, which global and which settable by user (global or local). > > > What is expected time penalty of additional parameter in hb_mt*() in > > comparison to TLS access? > > It will depend on hardware and C compiler. I expect that passing pointer > to HB_STACK will reduce the performance not more then 3-5% and it's IMHO > acceptable. The cost of accessing TLS/TSD data in current code in the > worst case will reduce the performance of pure PCODE evaluation about > 70% so it will be 3 times slower. But it's the worst case. On some platforms > it may be even smaller then passing pointer to HB_STACK so such modification > only for MT mode does not have big sense. But it will allow to use more > HVMs also in ST programs and in such case it's interesting extension. > If we also add support for calling PCODE function without executing C ones > then we will have nice VM to emulate MT mode in platforms which do not > have native MT support. > > best regards, > Przemek > _______________________________________________ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour -- __________ | | | |__| Maurilio Longo |_|_|_|____| farmaconsult s.r.l. _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
