On Mon, 03 Dec 2007, Mike Evans (Gmail) wrote: Hi Mike, thanks for informations about xbase++
> Xbase++ Its always MT (Even if you don't start a thread at least the GC is > running in its own Thread) Inspector thread which makes GC scan, polls incoming events and serve background tasks greatly helps to resolve some problems, f.e. it will allow to eliminate hb_inkeyPoll() from main HVM loop what will increase speed but it's a little bit different subject then support for MT in .prg code though bound in some cases, f.e. it's possible to add such support for Harbour MT even without MT in OS. Also number of OS threads does not have to be equal to number of user threads. Allocating thread and context switching costs so it's common practice in modern languages to use only few OS threads which server many language threads. Unfortunately it will be hard to make sth like that keeping current API so for sure the first version of MT in Harbur will allocate OS thread for each .prg thread. > >It can be done but please remember that xbase++ is single platform project > >with strictly defined runtime environment so it's much easier to reach > >such effect. > You are almost right. Xbase++ support natively OS2 also (except from > windows). Both are quite similar, > Also even if they have an excellent Multithtread engine they had also some > speed problems, with milticpu systems. So in the last few versions the lock > every thread on the same CPU (by default). If I remember correctly this > happen because they have only one thread for GC an if they use concurrently > many cpu the GC had to lock all the CPUs. The problem of executing GC in multi thread environment is not unique to xbase++. We will also have the same problem just like .NET have it. Stopping all threads during GC pass is the easiest solution and usually the only one. There are some garbage collectors (f.e. multicolor ones) designed to work "online" but they do not have to give much better performance. In some cases they are even less efficient then standard ones which stop all threads. But this we will discuss when we will have basic MT support. Now we will have to resolve the problem with cost of simple MT mode in HVM. We have much better situation then in xHarbour. Macrocompiler (and compiler) library is fully MT safe and we do not have any executions context variables which are not stored on HVM stack like puiClsTree in array structure which causes that super casting on the same object is not MT safe in xHarbour. RDD code is ready to use in MT mode and now I'll try to make the same with GT subsystem. When it will be ready then we will have to define what to do with some global variables/ resources used by RTL (probably it will be good to move set.c code from RTL to VM) and we can start to update VM for MT. This step should not take more then few days. Then we can add some MT extensions to language syntax like monitors (CRITICAL functions/procedures in xHarbour) or thread local static variables (f.e.: thread static s_var := 1) Because memvars will be visible in single thread only then we can also think about adding support for GLOBAL variables. BTW I'm interesting in variable visibility between threads in xbase++. I would like to see if we can easy replicate similar behavior. If yes then maybe we should not reinvent the wheel because it will be easier for users if we will make it compatible with xbase++ Can I read somewhere about it? best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
