Przemyslaw Czerpak wrote:
which can use it) so there is no simple answer. Without modifications
in core HVM code but changing only HVM stack functions it reduce
the speed of PCODE evaluation over twice in my Linux box.
As I said the most important problem is caused by the fact that
we are using very similar to Clipper API which forces using TSD/TLS.
In few years when new hardware will be commonly used and compilers
will support it the problem should be smaller and we can try to
create single library because the overhead will not be such big.
Hi,
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 )
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).
What is expected time penalty of additional parameter in hb_mt*() in
comparison to TLS access?
I'd argue with the naming :) but this looks like a very
elegant way to resolve this problem IMO.
We need a "new" API set which has native MT support.
(maybe even with some automatic remapping of the new
functions to the old one in case someone doesn't want
MT, in this case the context could be NULL)
Or the other way round:
-- SOURCE (both MT and non MT API compatible)
HB_FUNC( MYFUNC )
{
hb_retc( hb_parc( 1 ) );
}
-- TRANSLATED FOR MT
void HB_MYFUNC( HBCTX* _hb_ctx )
{
hb_retc_mt( _hb_ctx, hb_parc_mt( _hb_ctx, 1 ) );
}
-- TRANSLATED FOR NON MT (with "old" API kept)
void HB_MYFUNC( void )
{
hb_retc( hb_parc( 1 ) );
}
-- TRANSLATED FOR NON MT (keeping only one "new" MT compatible API)
void HB_MYFUNC( void )
{
hb_retc_mt( NULL, hb_parc_mt( NULL, 1 ) );
}
(or some other variation of this)
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
