Discussion:
Intresting corner of info
(too old to reply)
Massimo Belgrano
2009-02-18 18:15:06 UTC
Permalink
From a user's POV they are probably the same.
Maybe there are some aspects of xhb which I don't know and could make
the process different, but normally it's just a recompile and relink,
feature-wise Harbour is on par with xhb, and a plus Harbour is
cleaner, more robust, more portable and faster, it also has an xhb.lib
which aims to provide compatibility with features we've opted not to
include in the core product...

Read the rest of this most interesting and helpful article at
Clipper... Clipper... Clipper at http://cch4clipper.blogspot.com.

CCH
Clipper... Clipper... Clipper
http://cch4clipper.blogspot.com.
Viktor Szakáts
2009-02-18 19:58:26 UTC
Permalink
After reading into a few lines I realized I wrote this a few days ago ;)
I used to know Chee Chong Hwa from pre-Harbour days, on the
apropos that he had - I believe - the first internet page in Clipper.
These were the days when you were browsing with a Netscape
browser :)

Very nice person, I hope he will join our list once.

Brgds,
Viktor
Post by Massimo Belgrano
From a user's POV they are probably the same.
Maybe there are some aspects of xhb which I don't know and could make
the process different, but normally it's just a recompile and relink,
feature-wise Harbour is on par with xhb, and a plus Harbour is
cleaner, more robust, more portable and faster, it also has an xhb.lib
which aims to provide compatibility with features we've opted not to
include in the core product...
Read the rest of this most interesting and helpful article at
Clipper... Clipper... Clipper at http://cch4clipper.blogspot.com.
CCH
Clipper... Clipper... Clipper
http://cch4clipper.blogspot.com.
_______________________________________________
Harbour mailing list
http://lists.harbour-project.org/mailman/listinfo/harbour
Massimo Belgrano
2009-02-19 08:07:12 UTC
Permalink
I invite everybody give a reply to this poll
What is your favourite 32-bit Clipper-compatible Compiler ?
http://cch4clipper.blogspot.com
I am conducting a poll as above at http://cch4clipper.blogspot.com.
This is to enable me to determine the future contents of Clipper...
Clipper... Clipper.
TQ
CCH
After reading into a few lines I realized I wrote this a few days ago ;)
I used to know Chee Chong Hwa from pre-Harbour days, on the
apropos that he had - I believe - the first internet page in Clipper.
These were the days when you were browsing with a Netscape
browser :)
Very nice person, I hope he will join our list once.
Brgds,
Viktor
Post by Massimo Belgrano
From a user's POV they are probably the same.
Maybe there are some aspects of xhb which I don't know and could make
the process different, but normally it's just a recompile and relink,
feature-wise Harbour is on par with xhb, and a plus Harbour is
cleaner, more robust, more portable and faster, it also has an xhb.lib
which aims to provide compatibility with features we've opted not to
include in the core product...
Read the rest of this most interesting and helpful article at
Clipper... Clipper... Clipper at http://cch4clipper.blogspot.com.
CCH
Clipper... Clipper... Clipper
http://cch4clipper.blogspot.com.
_______________________________________________
Harbour mailing list
http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list
http://lists.harbour-project.org/mailman/listinfo/harbour
--
Massimo Belgrano

Albo Nazionale Informatici Professionisti 2620
Socio 2843 Associazione Informatici prof.

Analisi e sviluppo software per Lan e Web
Consulenza informatica - Formazione
Delta Informatica S.r.l. http://www.deltain.it
Via Torelli,31 - 28100 Novara - Tel: 0321/30281
Massimo Belgrano
2009-02-22 11:31:18 UTC
Permalink
This is intresting post of Steffen F. Pirsig of Alaska Software Inc
------------------------------------------------
i think Bruce ment client/server technology in a more general sense
not strictly related to c/s databases.

Regarding your browse/incompatiblity issue. I totally agree with you,
we have been experimented with the YUI too but found it to heavy
and waggly if you are using CSS and JS code coming from other
third parties. It always ended up with sideeffects or broken features.
In fact we used YUI to develop the first prototype of our new
www applications, unfortunately we realized that the knowledge
needed to create rich functional UI for the browser is to complex
and involves to many different technologies. While this can be handled
by people willing to invest into learning CSS, Javascript, Cross-Browser
issues, we realized, that this approach is far to complex for your
our customer base or target audience in terms of Xbase++.

Our second attempt was to use prototype only, simple clean
CSS and for the forms pure HTML markup. Parts of this web
application prototype are right now the foundation of the
current www application serving customer login, download,
role-base-authentification and so on. However we still feel this
is a to complex technology specifically bec. if you are developing
web applications related to data-entry, such as an ERP
over the web you are forced to learn JavaScript inside out.

Our last attempt was to create a simple transpiler, so
you can create a validation-method for a www form
element in Xbase++ and the Xbase++ code gets transpiled
into Javascript code. Therefore the developer has only to deal
with Xbase++ and some new Classes without any need for
Javascript or Ajax or Prototype knowledge. While this attempt
is the most promising right now it is also an attempt with an huge
investment on our side - so we put that on hold until SL1 is
released and Artica technologies are in community preview
stage.
YUI is not bad - but the learning curve is quite steep if you do not
already know javascript to the same level as Xbase++ - especially with
customers at your back, urging you to deliver results instead of promises
<g>
Yes thats exactly the point, using YUI makes things in the first step easy,
but
if you are working on a larger project, and if you are forced to use
javascript code
from other sources to add a feature YUI does not provide you are always
ending
up with the need to understand how YUI works inside out. Changing then
the 3rd-party javascript code or CSS to conform with YUI is a difficult and
time
consuming task. We invested into that as our first idea was to create a
Xbase++
infrastructure to support YUI as the standard web interface for Web 2.0
Xbase++ applications but we learned the knowledge to really deliver results,
and to do that in time under customers pressure is not possible without
being
a Javascript, YUI + CSS expert. So finally we decided to drop that idea,
simple because we don't want our customers to be JS + CS + YUI
experts - thats not the idea of a tool like Xbase++.
Nice idea - I like that. Please send it to me as soon as it is ready <g>
It was an experiment, just to get a proof of concept if that approach will
work better. It worked far better than anything else but we put that on hold
as we our current priorities are different.
BTW - is there a (undocumented) way to shut down WAA in a "clean" way from
the inside (from package level code). Currently I'm using QUIT, but I
don't
think this waits for all worker threads to be finished.
Not really, but what you can try is the following - i haven't testet it but
IMO it should work -:)

// This function queries the servers main window and
// sends a close message. This is just like you are sitting
// in front of the server and quitting it with a click on
// close icon.
//
FUNCTION MyPersonalShutdown()
LOCAL oDlg := &("GetRootDialog")()
PostAppEvent( xbeP_Close,,oDlg)
RETURN
Apparently it looks like we will have more n more ActiveX support in
coming versions of Xb++. Right ?
Not necessarily, we will fix issues and work on performance enhancements.
Other than that is not on our schedule. With Roger , Alaska Software
has agreed to
investigate and resolve issues related to CodeJock as this is what
Rogers and Alaska
Softwares customers want.
http://www.codejock.com/

---------------------------
I agree with you in terms of Terminal Server solutions,
specifically with respect to the positive sideeffect of
increased reliability and performance of dbf/ntx/cdx based
applications deloyed for a larger scale of end-users
without any database server.

However, the Terminal Server use-case is only good
if you have a reliable and "fast" permanent connection.
The neat thing with the web is that it is stateless so
connection drops, bad connections do not affect single
client experience in the same scale as it is with Terminal
Server. In addition Terminal Server may involve huge
Licensing costs plus require that all users are know by
the Servers account-mgmt or LDAP/ActiveDirectory.

I agree with you in terms of the UI experience for end-users
in terms of Web 2.0 applications, they lack a lot of usability
features. However I feel that the current emerging RIA
(Rich Internet Application) platforms such as Adobe Flex
or Silverlight are more likely to reach the level of UI
experience customers await from professional looking
and working data-entry ERP/CRM apps.

Unfortunately, Adobe Flex has to live with a lot of historical
burden in terms of its roots (Flash & ActionScript), while
Silverlight is right now too buggy and the workload in
means of memory consumption is far from being
acceptable. Anyway, both technologies look to me
very promising to delivery a rich end user experience
to the customer over the browser.

Therefore I think, that Terminal Server plays an important
role to provide remote application access for Windows Clients,
PDAs, Windows Mobile. But I also believe that not all deployment
scenarios can be fullfilled with Terminal Server.

Just a few thoughts on that subject,
Steffen F. Pirsig
Alaska Software Inc.

BTW: Sever 2008 allows application virtualization which is a
great feature to deploy only the application not a complete
desktop using Terminal Server. This way the remote application
behaves such as any other local-running windows application
on the remote desktop.

----------------------------
It is our goal to outperform any multi-user scenario in an network. However
it should
be clear that the PostgreSQL ISAM DatabaseEngine can not outperform

- single-user exclusive local file-access
- multi-processes/users shared local file-acess

use cases. As a matter of fact, a great deal of research has been put into
the PostgreSQL DatabaseEngine to provide best possible compatibility with
your existing soure code and business logic - optimized for navigational
data-access.

Again, our goal is to deliver increased performance and better
scaleability in multi user scenarios based on your existing source code.


--------------------------------
The PostgreSQL ISAM DatabaseEngine supports all Xbase++ navigational
commands and functions. This includes also all Index related operations,
including
compound indexes and user-defined-functions in index expression. A migration
tool is included, allowing you to transfer your data and data-model from
table/index
definition to a PostgreSQL Database
Massimo Belgrano
2009-02-22 11:39:56 UTC
Permalink
I invite everybody to vote harbour as preferred clipper compiler at
http://cch4clipper.blogspot.com

Thanks to last year of hard works of our special guru harbour is
realiable and fast
From a user's POV they are probably the same.
Maybe there are some aspects of xhb which I don't know and could make
the process different, but normally it's just a recompile and relink,
feature-wise Harbour is on par with xhb, and a plus Harbour is
cleaner, more robust, more portable and faster, it also has an xhb.lib
which aims to provide compatibility with features we've opted not to
include in the core product...
Read the rest of this most interesting and helpful article at
Clipper... Clipper... Clipper at http://cch4clipper.blogspot.com.
CCH
Clipper... Clipper... Clipper
http://cch4clipper.blogspot.com.
--
Massimo Belgrano
Massimo Belgrano
2009-02-23 09:48:22 UTC
Permalink
Another posting of Steffen that reply to xbase is the only multitread project

require a reply?

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.
From a user's POV they are probably the same.
Maybe there are some aspects of xhb which I don't know and could make
the process different, but normally it's just a recompile and relink,
feature-wise Harbour is on par with xhb, and a plus Harbour is
cleaner, more robust, more portable and faster, it also has an xhb.lib
which aims to provide compatibility with features we've opted not to
include in the core product...
Read the rest of this most interesting and helpful article at
Clipper... Clipper... Clipper at http://cch4clipper.blogspot.com.
CCH
Clipper... Clipper... Clipper
http://cch4clipper.blogspot.com.
--
Massimo Belgrano

Albo Nazionale Informatici Professionisti 2620
Socio 2843 Associazione Informatici prof.

Analisi e sviluppo software per Lan e Web
Consulenza informatica - Formazione
Delta Informatica S.r.l. http://www.deltain.it
Via Torelli,31 - 28100 Novara - Tel: 0321/30281
Massimo Belgrano
2009-02-23 09:50:51 UTC
Permalink
Follow prev
Multithreading as the ability to execute code in different code paths
is a feature of modern OS sinces decades. The problem with MT is that
it adds another dimension of complexity to the developers task. While
with single threaded apps. the developer needs only to think in a more
or less sequential way with MT each execution path adds a new
dimentions to the equation of programm complexity. Development
languages supporting MT such as Delphi, .NET (C#,VB) or Harbour and
xHarbour support MT thats correct, but they do not remove the burden
of correctness from the programmer. It is in the sole responsibility
of the programmer to ensure programm correctness in two different
areas; data-consistency and algorithm isolation.

The problem of data consistency occurs as soon as more than one thread
is accessing the same data - such as a simple string or an array.
Besides nuances in terms of single or multiple readers/writers the
consistency of the data must be ensured, so developers are forced to
use mutex-semaphores or other higher level concepts such monitors,
guards... to ensure data-consistency.

Algorithm isolation is somewhat related to data-consistency, it
becomes obvious that a linked-list accessed from multiple threads must
be protected otherwise dangling pointer occurs. But what about a
table/relation of a database. The problem here is that concurrency
inside the process can be resolved - but this type of "isolation" does
break the semantics of the isolation principles which are already
provided by the underlying dbms (sql-isolation-levels, record or file
locks, transactions). Therefore algorithm isolation/correctness is a
complete different beast as it is located at a very high semantic
level of the task.

Alaska Software has put an enormous amount of research efforts into
that area and we have more than a decade of practical experience with
that area based on real world customers and real world applications.
From that point of view I would like to reiterate my initial statement
"As of today there is still no tool available in the market which
provides that clean and easy to use way of multithreading".

Lets start with xHarbour, its MT implementation is not well thought,
as it provides MT features to the programmer without any model, just
the features. xHarbour even allows the usage of a workarea from
different threads which is a violation of fundamental dbms isolation
principles. In fact xHarbour ist just a system language in the sense
of MT and makes life not really easier compared with other system
languages. Therefore there is no value in besides being able to do MT.
Also keep in mind due to the historical burden of the VM and RT core
the MT feature is implemented in a way making it impossible to scale
in future multi-core scenarios (see later-note).

Harbour is better here because if follows more the principles of
Xbase++, while I am not sure if the Harbour people have decided to
adapt the Xbase++ model for compatibility reasons or not I am glad to
see that they followed our models point of view. The issues with
Harbour however is that it suffers from the shortcoming of its runtime
in general, the VM design and of course the way how datatypes - the
blood of a language - are handled. It is still in a 1980 architectual
style centered around the original concept how Clipper did it. This is
also true for xHarbour, so both suffer from the fact that MT was added
I think in 2007, while the VM and RT core is from 1999 - without
having MT in mind.

This is in fact one of the biggest differences between Xbase++ and the
"Harbours" from a pure architectual point of view, we designed a
runtime architecture from the beginning to be MT/MP and Distributed,
they designed a runtime based on the DOS Clipper blueprint.

In fact, I could argue on and on, specifically it it comes to
dedicated implementations of the Harbour runtime core or the Harbour
VM but sharing these type of technical details is of course
definitively not what I am paid for -;) Anyway allow me to make it
clear in a general terms.

First, any feature/functionality of Xbase++ is reentrant there is not
a single exception of this rule. Second, any datatype and storage type
is thread-safe regardless of its complexity so there is no way to
crash an Xbase++ process using multithreading. Third, the runtime
guarantees that there is no possibility of a deadlock in terms of its
internal state regardless what you are doing in different threads.
There is a clean isolation and inheritance relationship of settings
between different threads. In practical terms that means, you can
output to the console from different threads without any additional
code, you can execute methods or access state of GUI (XbasePARTS)
objects from different threads, you can create a codeblock which
detaches a local variable and pass it to another thread, you are
performing file I/O or executing a remote procedure call and in the
meanwhile the async. garbagge collector cleans up your memory - and
the list goes on... But in Xbase++ you can do all that without the
need to think about MT or ask a question such as "Is the ASort()
function thread safe" or can I change the caption of a GUI control
from another thread. Thats all a given, no restrictions apply, the
runtime does it all automatically for you.

Anyway, I like Harbour more than xHarbour in terms of MT support.
However the crux is still there, no real architecture around the
product, leading to the fact that MT is supported form a technical
point of view but not from a 4GL therefore leading to a potential of
unnecessary burden for the average programmers, and of course that was
and is still not the idea of Clipper as a tool.

Btw, the same is true for VO or so, they left the idea of the language
and moved to something more like a system -language, while I can
understand that somewhat I strongly disagree with that type of
language design for a simple reasons; its not practical in the long
term - we will see that in the following years as more and more multi
core system will find their way in the mainstream and developers need
to make use of them for performance and scaleability reasons. In 10 -
15 years from now we will have 100 if not thousands cores per die -
handling multithreading , synchronisation issues by hand becomes then
impossible, the same is true for offloading tasks for performance
reasons. So there is a need for a clean model in terms of the language
- thats at least into what we believe at Alaska Software. It goes even
further, the current attempty by MS in terms of multicore support with
VS2010 or NET 4.0 are IMO absolutely wrong, as they force the
developer to write code depending on the underlaying execution
infrastructure alias cores available. In other words, infrastructure
related code/algorithms get mixed with the original algorithm the
developers writes and of course the developer gets payed for. Thats a
catastrophic path which for sure does not contribute to increased
productivity and reliability of software solutions.

Funnily enough, the most critical, and most difficult aspect in that
area; getting performance gains from multi core usage is even not
touched with my technical arguments right now. However it adds another
dimension of complexity to the previous equation as it needs to take
into account the memory hierarchy which must be handled by a 4GL
runtime totally different as it is with the simple approach of
Harbour/xHarbour. Their RT core and VM needs a more or less complete
rewrite and redesign to go that path.

In other words, Xbase++ is playing in the Multithreading ballpark
since a decade. Harbour is still finding its way into the MT ballpark
while xHarbour is in that context at a dead-end.

I would bet that Xbase++ will play in the multicore ballpack while the
Harbours are still with their MT stuff.

In a more theoretical sense, it is important to understand that a
programming language and its infrastructure shall not adapt any
technical feature, requirement or hype. Because then the language and
infrastucture are getting more and more complicated up to an point of
lost control. Also backward compatibility and therefore protection of
existing investments becomes more and more a mess with Q&A costs going
through the roof.

Nor is it a good idea to provide software developers any freedom - the
point here is, a good MT modell does smoothly guide the developer
through the hurdels and most of the time is even not in the awareness
of the developer. The contrary is providing the developer all freedom,
but this leads to letting him first build the gun-powder, then the gun
to finally shoot a bullet -;)

Therefore let me rephrase my initial statement to be more specific;

As of today there is still no tool available in the market which
provides that clean and easy to use way of multithreading, however
there are other tools which support MT - but they support it just as
an technical feature without a modell and thats simple wrong as it
leads to additional dimensions in code complexity - finally ending in
applications with lesser reliability and overall quality.

Just my point of view on that subject - enough said

Steffen F. Pirsig
Przemyslaw Czerpak
2009-02-23 12:37:00 UTC
Permalink
On Mon, 23 Feb 2009, Massimo Belgrano wrote:

Hi,
Post by Massimo Belgrano
Follow prev
Multithreading as the ability to execute code in different code paths
is a feature of modern OS sinces decades. The problem with MT is that
it adds another dimension of complexity to the developers task. While
with single threaded apps. the developer needs only to think in a more
or less sequential way with MT each execution path adds a new
dimentions to the equation of programm complexity. Development
languages supporting MT such as Delphi, .NET (C#,VB) or Harbour and
xHarbour support MT thats correct, but they do not remove the burden
of correctness from the programmer. It is in the sole responsibility
of the programmer to ensure programm correctness in two different
areas; data-consistency and algorithm isolation.
I agree,
Post by Massimo Belgrano
The problem of data consistency occurs as soon as more than one thread
is accessing the same data - such as a simple string or an array.
Besides nuances in terms of single or multiple readers/writers the
consistency of the data must be ensured, so developers are forced to
use mutex-semaphores or other higher level concepts such monitors,
guards... to ensure data-consistency.
Yes, usually they are though different languages gives some additional
protection mechanisms here so not always is necessary to use user level
synchronization.
Post by Massimo Belgrano
Algorithm isolation is somewhat related to data-consistency, it
becomes obvious that a linked-list accessed from multiple threads must
be protected otherwise dangling pointer occurs. But what about a
table/relation of a database. The problem here is that concurrency
inside the process can be resolved - but this type of "isolation" does
break the semantics of the isolation principles which are already
provided by the underlying dbms (sql-isolation-levels, record or file
locks, transactions). Therefore algorithm isolation/correctness is a
complete different beast as it is located at a very high semantic
level of the task.
yes, it is.
Post by Massimo Belgrano
Alaska Software has put an enormous amount of research efforts into
that area and we have more than a decade of practical experience with
that area based on real world customers and real world applications.
From that point of view I would like to reiterate my initial statement
"As of today there is still no tool available in the market which
provides that clean and easy to use way of multithreading".
I was not making such "enormous amount of research efforts" ;-)
Just simply looked at good balance between performance, basic
protection and flexibility for programmers.
Post by Massimo Belgrano
Lets start with xHarbour, its MT implementation is not well thought,
as it provides MT features to the programmer without any model, just
the features. xHarbour even allows the usage of a workarea from
different threads which is a violation of fundamental dbms isolation
principles. In fact xHarbour ist just a system language in the sense
of MT and makes life not really easier compared with other system
languages. Therefore there is no value in besides being able to do MT.
Also keep in mind due to the historical burden of the VM and RT core
the MT feature is implemented in a way making it impossible to scale
in future multi-core scenarios (see later-note).
I agree. Giving the unprotected access to workareas is asking for a
troubles. It can create very serious problems (f.e. data corruption
in tables) and gives nothing for programmers because they have to use
own protection mechanisms to access the tables so final application
have to be reduced to the same level as using dbRequest()/dbRelease()
to lock/unlock the table. The difference is only that in such model
programmer has to implement everything itself.
Post by Massimo Belgrano
Harbour is better here because if follows more the principles of
Xbase++, while I am not sure if the Harbour people have decided to
adapt the Xbase++ model for compatibility reasons or not I am glad to
see that they followed our models point of view. The issues with
Harbour however is that it suffers from the shortcoming of its runtime
in general, the VM design and of course the way how datatypes - the
blood of a language - are handled. It is still in a 1980 architectual
style centered around the original concept how Clipper did it. This is
also true for xHarbour, so both suffer from the fact that MT was added
I think in 2007, while the VM and RT core is from 1999 - without
having MT in mind.
Here I can agree only partially.
1-st Harbour does not follow xbase++ model. With the exception to
xbase++ emulation level (xbase++ sync and thread classes, thread
functions and sync methods) the whole code is the result of my own
ideas. The only one idea I partially borrowed is dbRequest()/dbRelase()
semantic. Personally I wanted to introduce many workarea holders
(not only single zero area zone) and dbDetach()/dbAttach() functions.
Later I heard about xbase++ implementation and I've found the cargo
codeblock attaching as very nice feature so I implemented it but
internally it operates on workarea sets from my original idea and
still it's possible to introduce support for multiple WA zones if
we decide to add .prg level API for it. In some cases it maybe usable.
Also the internal WA isolation in native RDDs is different. For POSIX
systems it's necessary to introduce file handle sharing and this
mechanism is already used so now we can easy extended it adding support
for pseudo exclusive mode (other threads will be able to access tables
open in exclusive mode which is exclusive only for external programs)
or add common to aliased WA caches.
Of course Harbour supports also other xbase++ extensions but they were
added rather for compatibility with xbase++ on xbase++ users and internally
use basic Harbour MT API.

2-nd this old API from 1980 is a real problem in some places and probably
will be good to change it. But I also do not find the xbase++ API
as the only one final solution. Harbour gives full protection for read
access to complex items. User have to protect only write access
and only if he will want to change exactly the same item not
complex item member, f.e. this code:
aVal[ threadID() ] += aVal[ threadID() ] * 2 + 100
is MT safe in Harbour even if the same aVal is used by many different
threads. Important is the fact that each thread operates on different
aVal items and aVal is not resized. Otherwise it may cause data corruption.
But when complex items can be resized the we usually need additional
protection also in xbase++ because user code makes many operations which
have to be atomic in some logical sense so in most of cases there is
only one difference here between Harbour and xbase++: in xbase++ with
full internal protection and missing user protection RT error is generated.
In Harbour it may cause internal data corruption. I agree here that it's
very important difference but in mouse of such cases we are talking about
wrong user code which needs additional user protection in both languages.
And here we have one fundamental question:
What is the cost of internal protection for scalability?
and if we can or cannot accept it. My personal feeling is that the cost
will be high, even very high but I haven't made any tests myself though
some xbase++ users confirmed that it's a problem in xbase++.
I'm really interested in some scalability tests of xbase++ and Harbour.
It could give few very important answers. If some xbase++ user can port
tests/speedtst.prg to xbase++ then it will be very helpful.

Of course it's possible that I missed something here but I've never used
xbase++ and I cannot see its source code so I only guess how some things
are implemented in this language.
Post by Massimo Belgrano
This is in fact one of the biggest differences between Xbase++ and the
"Harbours" from a pure architectual point of view, we designed a
runtime architecture from the beginning to be MT/MP and Distributed,
they designed a runtime based on the DOS Clipper blueprint.
In fact, I could argue on and on, specifically it it comes to
dedicated implementations of the Harbour runtime core or the Harbour
VM but sharing these type of technical details is of course
definitively not what I am paid for -;) Anyway allow me to make it
clear in a general terms.
See above. It's not such clear as you said.
I think that you will find users which can say that the cost of
scalability is definitively not what they be paid for. Especially
when the missing user protection is also problem for xbase++ and
the bad results are only different. For sure RT error is much better
then internal data corruption but how much users can paid for such
functionality.
Post by Massimo Belgrano
First, any feature/functionality of Xbase++ is reentrant there is not
a single exception of this rule. Second, any datatype and storage type
is thread-safe regardless of its complexity so there is no way to
crash an Xbase++ process using multithreading. Third, the runtime
guarantees that there is no possibility of a deadlock in terms of its
internal state regardless what you are doing in different threads.
There is a clean isolation and inheritance relationship of settings
between different threads. In practical terms that means, you can
output to the console from different threads without any additional
code, you can execute methods or access state of GUI (XbasePARTS)
objects from different threads, you can create a codeblock which
detaches a local variable and pass it to another thread, you are
performing file I/O or executing a remote procedure call and in the
meanwhile the async. garbagge collector cleans up your memory - and
the list goes on... But in Xbase++ you can do all that without the
need to think about MT or ask a question such as "Is the ASort()
function thread safe" or can I change the caption of a GUI control
from another thread. Thats all a given, no restrictions apply, the
runtime does it all automatically for you.
Most of the above is also true in Harbour with the exception to
missing GUI components and obligatory internal item storage protection.
But it's the subject of efficiency discussed above.
Let's make some scalability tests and we can decide if we want to pay
the same cost of xbase++ users.
Post by Massimo Belgrano
Anyway, I like Harbour more than xHarbour in terms of MT support.
However the crux is still there, no real architecture around the
product, leading to the fact that MT is supported form a technical
point of view but not from a 4GL therefore leading to a potential of
unnecessary burden for the average programmers, and of course that was
and is still not the idea of Clipper as a tool.
The only one fundamental difference between Harbour and xbase++ in the
above is obligatory internal items protection. At least visible for me
now and as I said the cost of such functionality may not be acceptable
for users. But let's make some real tests to see how big problem it
creates in real life.
Post by Massimo Belgrano
Btw, the same is true for VO or so, they left the idea of the language
and moved to something more like a system -language, while I can
understand that somewhat I strongly disagree with that type of
language design for a simple reasons; its not practical in the long
term - we will see that in the following years as more and more multi
core system will find their way in the mainstream and developers need
to make use of them for performance and scaleability reasons. In 10 -
15 years from now we will have 100 if not thousands cores per die -
handling multithreading , synchronisation issues by hand becomes then
impossible, the same is true for offloading tasks for performance
reasons. So there is a need for a clean model in terms of the language
- thats at least into what we believe at Alaska Software. It goes even
further, the current attempty by MS in terms of multicore support with
VS2010 or NET 4.0 are IMO absolutely wrong, as they force the
developer to write code depending on the underlaying execution
infrastructure alias cores available. In other words, infrastructure
related code/algorithms get mixed with the original algorithm the
developers writes and of course the developer gets payed for. Thats a
catastrophic path which for sure does not contribute to increased
productivity and reliability of software solutions.
I agree with you only partially. Over some reasonable cost limit
the MT programing stops to be usable and is much more efficient,
safer and easier to use separated processes. The cost of data
exchanging between them will be simply smaller the cost of internal
obligatory MT synchronization. So why to use MT mode? For marketing
reasons?
Post by Massimo Belgrano
Funnily enough, the most critical, and most difficult aspect in that
area; getting performance gains from multi core usage is even not
touched with my technical arguments right now. However it adds another
dimension of complexity to the previous equation as it needs to take
into account the memory hierarchy which must be handled by a 4GL
runtime totally different as it is with the simple approach of
Harbour/xHarbour. Their RT core and VM needs a more or less complete
rewrite and redesign to go that path.
I do not see bigger problems with Harbour core code modifications.
If we decide that it's worth then I'll implement it.
Probably the real problem will be forcing different API to 3-rd party
developers. Here we probably should chose something close to xbase++
C API to not introduce additional problems for 3-rd party developers
which have to create code for both projects to have some basic
compatibility f.e. at C preprocessor level.
Anyhow I'm still not sure I want to pay for the cost of full item
access serialization.
Post by Massimo Belgrano
In other words, Xbase++ is playing in the Multithreading ballpark
since a decade. Harbour is still finding its way into the MT ballpark
while xHarbour is in that context at a dead-end.
I would bet that Xbase++ will play in the multicore ballpack while the
Harbours are still with their MT stuff.
And it's highly possible that it will happen. But Harbour is free
project and if we decide that adding full item protection with the
cost of speed is valuable feature then maybe we implement it.
It's also possible that we add such functionality as alternative VM
library. Just like now we have hbvm and hbvmmt we will have hbvmpmt
(protected mt).
Post by Massimo Belgrano
In a more theoretical sense, it is important to understand that a
programming language and its infrastructure shall not adapt any
technical feature, requirement or hype. Because then the language and
infrastucture are getting more and more complicated up to an point of
lost control. Also backward compatibility and therefore protection of
existing investments becomes more and more a mess with Q&A costs going
through the roof.
_FULLY_AGREE_. Things should be as simple as possible. Any hacks or
workarounds for single features in longer terms create serious problems
and blocks farther developing.
For me it was the main of xHarbour problem when I was working on this
project.
Post by Massimo Belgrano
Nor is it a good idea to provide software developers any freedom - the
point here is, a good MT modell does smoothly guide the developer
through the hurdels and most of the time is even not in the awareness
of the developer. The contrary is providing the developer all freedom,
but this leads to letting him first build the gun-powder, then the gun
to finally shoot a bullet -;)
:-)
Post by Massimo Belgrano
Therefore let me rephrase my initial statement to be more specific;
As of today there is still no tool available in the market which
provides that clean and easy to use way of multithreading, however
there are other tools which support MT - but they support it just as
an technical feature without a modell and thats simple wrong as it
leads to additional dimensions in code complexity - finally ending in
applications with lesser reliability and overall quality.
Just my point of view on that subject - enough said
Thank you very much for this very interesting text.
I hope that now the main internal difference between Harbour and xbase++
is well visible for users.
To the above we should add yet tests/speedtst.prg results to compare
scalability so we will know the real cost which is important part of
the above description.
I'm very interesting in real life results and I hope that some xbase++
users will port tests/speedtst.prg to xbase++ so we can compare the
results.

best regards,
Przemek
Viktor Szakáts
2009-02-23 13:03:36 UTC
Permalink
Hi Przemek,

Thanks for this thoughtful conversation.
Just a few things that sprang to my mind regarding current MT
issues in Harbour while reading both Steffen's and your text:

- hbct windowing has the current window as an app global
data. This makes it difficult (or even impossible?) to
start a new thread which operates in its own windows,
as the threads are stealing focus from each other.
(main app thread focus changes are difficult to protect
by mutexes)
- hbct has other .c parts which are non-MT safe.
- Moving static to "thread static" on the .c level can be
a need for other 3rd party code.

This leads to one of the NOTEs I've made in ChangeLog:
Should Harbour have a way to attach custom information
to a thread? This may give the path to solve some of these
problems, so it seems to me at least.

[ Maybe I'm banging open doors and the support is there,
but couldn't find it, yet. ]

Brgds,
Viktor
Post by Przemyslaw Czerpak
Hi,
Post by Massimo Belgrano
Follow prev
Multithreading as the ability to execute code in different code paths
is a feature of modern OS sinces decades. The problem with MT is that
it adds another dimension of complexity to the developers task. While
with single threaded apps. the developer needs only to think in a more
or less sequential way with MT each execution path adds a new
dimentions to the equation of programm complexity. Development
languages supporting MT such as Delphi, .NET (C#,VB) or Harbour and
xHarbour support MT thats correct, but they do not remove the burden
of correctness from the programmer. It is in the sole responsibility
of the programmer to ensure programm correctness in two different
areas; data-consistency and algorithm isolation.
I agree,
Post by Massimo Belgrano
The problem of data consistency occurs as soon as more than one thread
is accessing the same data - such as a simple string or an array.
Besides nuances in terms of single or multiple readers/writers the
consistency of the data must be ensured, so developers are forced to
use mutex-semaphores or other higher level concepts such monitors,
guards... to ensure data-consistency.
Yes, usually they are though different languages gives some additional
protection mechanisms here so not always is necessary to use user level
synchronization.
Post by Massimo Belgrano
Algorithm isolation is somewhat related to data-consistency, it
becomes obvious that a linked-list accessed from multiple threads must
be protected otherwise dangling pointer occurs. But what about a
table/relation of a database. The problem here is that concurrency
inside the process can be resolved - but this type of "isolation" does
break the semantics of the isolation principles which are already
provided by the underlying dbms (sql-isolation-levels, record or file
locks, transactions). Therefore algorithm isolation/correctness is a
complete different beast as it is located at a very high semantic
level of the task.
yes, it is.
Post by Massimo Belgrano
Alaska Software has put an enormous amount of research efforts into
that area and we have more than a decade of practical experience with
that area based on real world customers and real world applications.
From that point of view I would like to reiterate my initial statement
"As of today there is still no tool available in the market which
provides that clean and easy to use way of multithreading".
I was not making such "enormous amount of research efforts" ;-)
Just simply looked at good balance between performance, basic
protection and flexibility for programmers.
Post by Massimo Belgrano
Lets start with xHarbour, its MT implementation is not well thought,
as it provides MT features to the programmer without any model, just
the features. xHarbour even allows the usage of a workarea from
different threads which is a violation of fundamental dbms isolation
principles. In fact xHarbour ist just a system language in the sense
of MT and makes life not really easier compared with other system
languages. Therefore there is no value in besides being able to do MT.
Also keep in mind due to the historical burden of the VM and RT core
the MT feature is implemented in a way making it impossible to scale
in future multi-core scenarios (see later-note).
I agree. Giving the unprotected access to workareas is asking for a
troubles. It can create very serious problems (f.e. data corruption
in tables) and gives nothing for programmers because they have to use
own protection mechanisms to access the tables so final application
have to be reduced to the same level as using dbRequest()/dbRelease()
to lock/unlock the table. The difference is only that in such model
programmer has to implement everything itself.
Post by Massimo Belgrano
Harbour is better here because if follows more the principles of
Xbase++, while I am not sure if the Harbour people have decided to
adapt the Xbase++ model for compatibility reasons or not I am glad to
see that they followed our models point of view. The issues with
Harbour however is that it suffers from the shortcoming of its runtime
in general, the VM design and of course the way how datatypes - the
blood of a language - are handled. It is still in a 1980 architectual
style centered around the original concept how Clipper did it. This is
also true for xHarbour, so both suffer from the fact that MT was added
I think in 2007, while the VM and RT core is from 1999 - without
having MT in mind.
Here I can agree only partially.
1-st Harbour does not follow xbase++ model. With the exception to
xbase++ emulation level (xbase++ sync and thread classes, thread
functions and sync methods) the whole code is the result of my own
ideas. The only one idea I partially borrowed is dbRequest()/dbRelase()
semantic. Personally I wanted to introduce many workarea holders
(not only single zero area zone) and dbDetach()/dbAttach() functions.
Later I heard about xbase++ implementation and I've found the cargo
codeblock attaching as very nice feature so I implemented it but
internally it operates on workarea sets from my original idea and
still it's possible to introduce support for multiple WA zones if
we decide to add .prg level API for it. In some cases it maybe usable.
Also the internal WA isolation in native RDDs is different. For POSIX
systems it's necessary to introduce file handle sharing and this
mechanism is already used so now we can easy extended it adding support
for pseudo exclusive mode (other threads will be able to access tables
open in exclusive mode which is exclusive only for external programs)
or add common to aliased WA caches.
Of course Harbour supports also other xbase++ extensions but they were
added rather for compatibility with xbase++ on xbase++ users and internally
use basic Harbour MT API.
2-nd this old API from 1980 is a real problem in some places and probably
will be good to change it. But I also do not find the xbase++ API
as the only one final solution. Harbour gives full protection for read
access to complex items. User have to protect only write access
and only if he will want to change exactly the same item not
aVal[ threadID() ] += aVal[ threadID() ] * 2 + 100
is MT safe in Harbour even if the same aVal is used by many different
threads. Important is the fact that each thread operates on different
aVal items and aVal is not resized. Otherwise it may cause data corruption.
But when complex items can be resized the we usually need additional
protection also in xbase++ because user code makes many operations which
have to be atomic in some logical sense so in most of cases there is
only one difference here between Harbour and xbase++: in xbase++ with
full internal protection and missing user protection RT error is generated.
In Harbour it may cause internal data corruption. I agree here that it's
very important difference but in mouse of such cases we are talking about
wrong user code which needs additional user protection in both languages.
What is the cost of internal protection for scalability?
and if we can or cannot accept it. My personal feeling is that the cost
will be high, even very high but I haven't made any tests myself though
some xbase++ users confirmed that it's a problem in xbase++.
I'm really interested in some scalability tests of xbase++ and Harbour.
It could give few very important answers. If some xbase++ user can port
tests/speedtst.prg to xbase++ then it will be very helpful.
Of course it's possible that I missed something here but I've never used
xbase++ and I cannot see its source code so I only guess how some things
are implemented in this language.
Post by Massimo Belgrano
This is in fact one of the biggest differences between Xbase++ and the
"Harbours" from a pure architectual point of view, we designed a
runtime architecture from the beginning to be MT/MP and Distributed,
they designed a runtime based on the DOS Clipper blueprint.
In fact, I could argue on and on, specifically it it comes to
dedicated implementations of the Harbour runtime core or the Harbour
VM but sharing these type of technical details is of course
definitively not what I am paid for -;) Anyway allow me to make it
clear in a general terms.
See above. It's not such clear as you said.
I think that you will find users which can say that the cost of
scalability is definitively not what they be paid for. Especially
when the missing user protection is also problem for xbase++ and
the bad results are only different. For sure RT error is much better
then internal data corruption but how much users can paid for such
functionality.
Post by Massimo Belgrano
First, any feature/functionality of Xbase++ is reentrant there is not
a single exception of this rule. Second, any datatype and storage type
is thread-safe regardless of its complexity so there is no way to
crash an Xbase++ process using multithreading. Third, the runtime
guarantees that there is no possibility of a deadlock in terms of its
internal state regardless what you are doing in different threads.
There is a clean isolation and inheritance relationship of settings
between different threads. In practical terms that means, you can
output to the console from different threads without any additional
code, you can execute methods or access state of GUI (XbasePARTS)
objects from different threads, you can create a codeblock which
detaches a local variable and pass it to another thread, you are
performing file I/O or executing a remote procedure call and in the
meanwhile the async. garbagge collector cleans up your memory - and
the list goes on... But in Xbase++ you can do all that without the
need to think about MT or ask a question such as "Is the ASort()
function thread safe" or can I change the caption of a GUI control
from another thread. Thats all a given, no restrictions apply, the
runtime does it all automatically for you.
Most of the above is also true in Harbour with the exception to
missing GUI components and obligatory internal item storage protection.
But it's the subject of efficiency discussed above.
Let's make some scalability tests and we can decide if we want to pay
the same cost of xbase++ users.
Post by Massimo Belgrano
Anyway, I like Harbour more than xHarbour in terms of MT support.
However the crux is still there, no real architecture around the
product, leading to the fact that MT is supported form a technical
point of view but not from a 4GL therefore leading to a potential of
unnecessary burden for the average programmers, and of course that was
and is still not the idea of Clipper as a tool.
The only one fundamental difference between Harbour and xbase++ in the
above is obligatory internal items protection. At least visible for me
now and as I said the cost of such functionality may not be acceptable
for users. But let's make some real tests to see how big problem it
creates in real life.
Post by Massimo Belgrano
Btw, the same is true for VO or so, they left the idea of the language
and moved to something more like a system -language, while I can
understand that somewhat I strongly disagree with that type of
language design for a simple reasons; its not practical in the long
term - we will see that in the following years as more and more multi
core system will find their way in the mainstream and developers need
to make use of them for performance and scaleability reasons. In 10 -
15 years from now we will have 100 if not thousands cores per die -
handling multithreading , synchronisation issues by hand becomes then
impossible, the same is true for offloading tasks for performance
reasons. So there is a need for a clean model in terms of the language
- thats at least into what we believe at Alaska Software. It goes even
further, the current attempty by MS in terms of multicore support with
VS2010 or NET 4.0 are IMO absolutely wrong, as they force the
developer to write code depending on the underlaying execution
infrastructure alias cores available. In other words, infrastructure
related code/algorithms get mixed with the original algorithm the
developers writes and of course the developer gets payed for. Thats a
catastrophic path which for sure does not contribute to increased
productivity and reliability of software solutions.
I agree with you only partially. Over some reasonable cost limit
the MT programing stops to be usable and is much more efficient,
safer and easier to use separated processes. The cost of data
exchanging between them will be simply smaller the cost of internal
obligatory MT synchronization. So why to use MT mode? For marketing
reasons?
Post by Massimo Belgrano
Funnily enough, the most critical, and most difficult aspect in that
area; getting performance gains from multi core usage is even not
touched with my technical arguments right now. However it adds another
dimension of complexity to the previous equation as it needs to take
into account the memory hierarchy which must be handled by a 4GL
runtime totally different as it is with the simple approach of
Harbour/xHarbour. Their RT core and VM needs a more or less complete
rewrite and redesign to go that path.
I do not see bigger problems with Harbour core code modifications.
If we decide that it's worth then I'll implement it.
Probably the real problem will be forcing different API to 3-rd party
developers. Here we probably should chose something close to xbase++
C API to not introduce additional problems for 3-rd party developers
which have to create code for both projects to have some basic
compatibility f.e. at C preprocessor level.
Anyhow I'm still not sure I want to pay for the cost of full item
access serialization.
Post by Massimo Belgrano
In other words, Xbase++ is playing in the Multithreading ballpark
since a decade. Harbour is still finding its way into the MT ballpark
while xHarbour is in that context at a dead-end.
I would bet that Xbase++ will play in the multicore ballpack while the
Harbours are still with their MT stuff.
And it's highly possible that it will happen. But Harbour is free
project and if we decide that adding full item protection with the
cost of speed is valuable feature then maybe we implement it.
It's also possible that we add such functionality as alternative VM
library. Just like now we have hbvm and hbvmmt we will have hbvmpmt
(protected mt).
Post by Massimo Belgrano
In a more theoretical sense, it is important to understand that a
programming language and its infrastructure shall not adapt any
technical feature, requirement or hype. Because then the language and
infrastucture are getting more and more complicated up to an point of
lost control. Also backward compatibility and therefore protection of
existing investments becomes more and more a mess with Q&A costs going
through the roof.
_FULLY_AGREE_. Things should be as simple as possible. Any hacks or
workarounds for single features in longer terms create serious problems
and blocks farther developing.
For me it was the main of xHarbour problem when I was working on this
project.
Post by Massimo Belgrano
Nor is it a good idea to provide software developers any freedom - the
point here is, a good MT modell does smoothly guide the developer
through the hurdels and most of the time is even not in the awareness
of the developer. The contrary is providing the developer all freedom,
but this leads to letting him first build the gun-powder, then the gun
to finally shoot a bullet -;)
:-)
Post by Massimo Belgrano
Therefore let me rephrase my initial statement to be more specific;
As of today there is still no tool available in the market which
provides that clean and easy to use way of multithreading, however
there are other tools which support MT - but they support it just as
an technical feature without a modell and thats simple wrong as it
leads to additional dimensions in code complexity - finally ending in
applications with lesser reliability and overall quality.
Just my point of view on that subject - enough said
Thank you very much for this very interesting text.
I hope that now the main internal difference between Harbour and xbase++
is well visible for users.
To the above we should add yet tests/speedtst.prg results to compare
scalability so we will know the real cost which is important part of
the above description.
I'm very interesting in real life results and I hope that some xbase++
users will port tests/speedtst.prg to xbase++ so we can compare the
results.
best regards,
Przemek
_______________________________________________
Harbour mailing list
http://lists.harbour-project.org/mailman/listinfo/harbour
Przemyslaw Czerpak
2009-02-23 13:27:08 UTC
Permalink
On Mon, 23 Feb 2009, Szak�ts Viktor wrote:

Hi.
Post by Viktor Szakáts
Thanks for this thoughtful conversation.
Just a few things that sprang to my mind regarding current MT
- hbct windowing has the current window as an app global
data. This makes it difficult (or even impossible?) to
start a new thread which operates in its own windows,
as the threads are stealing focus from each other.
(main app thread focus changes are difficult to protect
by mutexes)
- hbct has other .c parts which are non-MT safe.
Yes, some for contrib code should be fixed. I cleaned only core
code and some elements of contrib code which I needed for my
own use. The thread local CTWIN current windows setting is
on my TODO list and I'll make it ASAP. I'll also clean the
files.c code I guess you are thinking about and document
the existing method close open directory handle or add new
one.
Post by Viktor Szakáts
- Moving static to "thread static" on the .c level can be
a need for other 3rd party code.
We already have it (TSD) and it's used in RTL code though
maybe I should think about a little bit different API though
static initialization which greatly simplify the user code
reduces my possibilities.
Post by Viktor Szakáts
Should Harbour have a way to attach custom information
to a thread? This may give the path to solve some of these
problems, so it seems to me at least.
[ Maybe I'm banging open doors and the support is there,
but couldn't find it, yet. ]
See how TSD is used in some RTL functions.

best regards,
Przemek
Viktor Szakáts
2009-02-23 13:40:53 UTC
Permalink
Post by Przemyslaw Czerpak
Post by Viktor Szakáts
- hbct windowing has the current window as an app global
data. This makes it difficult (or even impossible?) to
start a new thread which operates in its own windows,
as the threads are stealing focus from each other.
(main app thread focus changes are difficult to protect
by mutexes)
- hbct has other .c parts which are non-MT safe.
Yes, some for contrib code should be fixed. I cleaned only core
code and some elements of contrib code which I needed for my
own use. The thread local CTWIN current windows setting is
on my TODO list and I'll make it ASAP. I'll also clean the
files.c code I guess you are thinking about and document
the existing method close open directory handle or add new
one.
Yes, a file find handle is closed only at app exit. On Windows
this locks the directory (not possible to remove it for example).

For most of these file functions we have now equivalents in
core, so they can be worked around easily.

CTWIN mod would be great, just take your time with it.
Post by Przemyslaw Czerpak
Post by Viktor Szakáts
- Moving static to "thread static" on the .c level can be
a need for other 3rd party code.
We already have it (TSD) and it's used in RTL code though
maybe I should think about a little bit different API though
static initialization which greatly simplify the user code
reduces my possibilities.
Okay, this was what I had in mind exactly. The API is IMO
perfectly good. Maybe some sort of named hash table could
make it simpler, but also heavier I guess. Anyhow even such
additional API can be built upon the current one.

Brgds,
Viktor
Przemyslaw Czerpak
2009-02-23 13:56:29 UTC
Permalink
On Mon, 23 Feb 2009, Szak�ts Viktor wrote:

Hi,
Post by Viktor Szakáts
Yes, a file find handle is closed only at app exit. On Windows
this locks the directory (not possible to remove it for example).
Not only. FILESEEK( NIL ) closes it. We can document it or
introduce new function.
The second is important functionality which can be used in DOS
based OS-es as some type of protection/synchronization mechanism.
For me the only one missing functionality is moving two static
variables to TSD.
Post by Viktor Szakáts
Post by Przemyslaw Czerpak
Post by Viktor Szakáts
- Moving static to "thread static" on the .c level can be
a need for other 3rd party code.
We already have it (TSD) and it's used in RTL code though
maybe I should think about a little bit different API though
static initialization which greatly simplify the user code
reduces my possibilities.
Okay, this was what I had in mind exactly. The API is IMO
perfectly good. Maybe some sort of named hash table could
make it simpler, but also heavier I guess. Anyhow even such
additional API can be built upon the current one.
Yes, any potential extensions I wanted to introduce as wrappers
to existing code.

best regards,
Przemek
Przemyslaw Czerpak
2009-02-23 10:57:57 UTC
Permalink
On Mon, 23 Feb 2009, Massimo Belgrano wrote:

Hi,
Post by Massimo Belgrano
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
Phil Barnett
2009-02-24 07:24:28 UTC
Permalink
Post by Massimo Belgrano
Another posting of Steffen that reply to xbase is the only multitread project
require a reply?
Steffen's Response to my post on Pritpal Bedi take on Multi-
threading.
Thank you for posting this. We should welcome input like this. It's very
difficult to get a reasonably objective expert opinion such as this one.
This was a very valuable critique, regardless of it not having perfect
accuracy. Much of it is right on the money.

Continue reading on narkive:
Loading...