On Mon, 23 Feb 2009, Massimo Belgrano wrote: Hi,
> Steffen's Response to my post on Pritpal Bedi take on Multi- > threading. > Sorry to use your blog to comment on the comments of others, as I > think this is not the idea of a blog. Anyway please allow me to > clarify my statement. I said "clean and easy to use way of > multithreading", i didn't say the Harbours don't support > Multithreading. My statement is still true, even so Harbour and > xHarbour have implemented the ability to execute code in multiple > threads and have implemented some of the interfaces Xbase++ provides > in one way or another. They are still far away from the idea and > concepts of Xbase++ in that area. In addition Harbour and xHarbour > implemented different semantics of isolation. Which makes porting of > complex MT applications for sure a mess. Let me clarify that. It's not true. 1-st Harbour and xHarbour use different MT implementation and they should not be confused. In Harbour it's possible to use threads like in xbase++. It support thread and signal classes/objects, the concept of zero zone for open workareas (dbRequest()/dbRelease()), SYNC object methods, isolated SET and RDD settings, coping or sharing memvars with parent threads. Also xbase++ thread related functions like ThreadID(), ThreadObject(), ThreadWait(), ThreadWaitAll() are supported. It's highly possible that I haven't replicated xbase++ behavior exactly (f.e. the implementation of THREAD class should be extended yet to add support for thread restarting when thread interval is set but it's rather simple .prg code and I hope that xbase++ users which are interested in exact emulation will make it. I'm not xbase++ user so I cannot easy test the details of implementation. Harbour does not support thread priority but it's not multiplatform and portable feature so it cannot be well implemented. Anyhow in few lines it can be added for those platforms which are supported by xbase++. But in Harbour you can also use other things which does not exists in xbase++. The very important is also scalability which is far much better then in xbase++ or in xHarbour so if you have multi CPU machine you can expect that the speed of MT application will be noticeable improved. The mutexes in Harbour give very flexible synchronization mechanism. They can be used as message queues, conditional variables or simple mutexes. PRIVATE and PUBLIC sharing or coping is optional and controlled by user. It's possible to allocate many console windows in single thread or in many threads. Console windows can be shared between threads or can be dedicated to single thread only. Harbour supports THREAD STATIC variables and they are used in core code. It means that Clipper's code which need static variables like getlist implementation is MT safe in Harbour. It also gives very powerful mechanism for MT programmers. There are also many other things related to MT programming which seems to be unique to Harbour and does not exist in xbase++. In summary Harbour offers xbase++ compatible MT API but rather as optional feature for programmers because it provides own more powerful and flexible one and the final applications are much better scalable. best regards, Przemek _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
