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
