And this is the reply from xHarbour expert: Pritpal Bedi ha scritto: > Jimmy > >>> :-) Which means that you cannot work on the same area from different >>> threads. >> you can use Xbase++ ZeroSpace() to switch Workspace if you want ...
I cannot see any relation with the problem at stake. > > Absolutely right. Today Przemek has committed exactly same behaviour as of > Xbase++ > > **************************** > 2008-09-20 00:42 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > + harbour/source/rdd/wadetach.c > + added .prg functions: > hb_waDetach( [<nWorkArea>|<cAlias>], [<xCargo>] ) -> <lSuccess> > hb_waRequest( [<cAlias>], [<lFreeArea>], [<@xCargo>], [<lWait>] ) > -> <lSuccess> > The first one detach workarea from current thread and move it > to special hidden holder. Before detaching all relations (parent > and child) to detached workarea are cleared. > The second one restores area from the holder and attach it > to calling thread. > + added xBase++ compatible functions DbRelease() / DbRequest() > xBase++ users please test. If possible please also check what xBase++ > does with relations and active RLOCKs/FLOCK on released WA. > **************************** > This has nothing to do with MT... > > ... what happend if you use different Threads and call external DLL >> where you have to use Stacks and Pointer ? >> > > This is interesting point. I will forward it to Harbour NG. > Ehm... are you really sure you know what you're talking about? The stack pointer in Xharbour is held in thread-local-stack; this means that a DLL can transparently receive anything it needs to have about the local execution context at 0 cost. >> i do not know how MT model in xharbour work, but we had that Discussion >> in Xbase++ long time ago. You might call it a limitation but i do not feel >> limited by Xbase++ MT when i have the Security that they are realy >> Thread - "Safe" >> > > Exactly my view point. MT looses all its glory if it is not self contained. ... MT has not to be glory. It has to be useful. Usefulness lies in the possible pattern usage. Reducing possible pattern usage reduces usefulness. Also, thread safety has nothing to do with the hard limits you impose on the developers... as the Java language learned the hard way, loosing market shares against .NET and having to rewrite the vast majority of multi-threading related stuff in 1.5 and 1.6 machines. > >> i can not see a sense to work from 2 Thread to same WorkspaceArea >> on same DBF ... what happen if 1 Thread fail (and Record ist locked) ? >> > > I confirm. The fact that you cannot see a solution doesn't mean another developer has your same limited views. What happens if a thread fails and you have a mutex still locked? --- will private variables not being shared across threads save your application? -- of course, no. Thread safety has nothing to do with what you are forbidden to do. You can do pretty thread unsafe programs even with the most protective language, and the other way around, you can do pretty thread safe programs even with the most relaxed MT paradigms. However, if you want to see the sense, a thread may be in charge of a seek, leaving the record pointer in a position and signaling another thread that would be in charge to process the found record. As mass-storage operations and memory-CPU intensive calculus have different operational speeds, this makes lots of sense. (Even if there are other ways to do that, as i.e. passing the record number around, it doesn't mean this solution isn't "right" as the others). > >> same with PUBLIC and PRIVATE, which you can accsess from each >> Thread in Xbase++ ... but did you "modify" those Memvar at runtime ? > > [Harbour] Even STATICS can be declared thread safe with keyword > THREAD STATIC. This feature is not available in Xbase++ also, correct > me if I am wrong because I left development on Xbase++ long back. > The fact that there is a keyword to do such things hasn't any relation with the basic model. In example, xharobour may have THREAD LOCAL PUBLIC/PRIVATE/AREA declared in someway. Oh. Actually it has. Just don't use them from other threads! (wasn't that hard, was it?) Seriously; thread local statics are a good idea, as they are explicitly meant to have different value bound to the same symbol in different threads. It's a thing you want to have in a language. You can add it to XHarbour with a couple of changes in the grammar file and some small changes in VM stack; it's probably 30 minutes work. >> i do not know how MT model in xharbour "talk" between Thread ? >> how to "signal" others Threads ? >> how to send Events to other Thread ? >> how to access Class Var from other Threads ? > .... I don't get your point. Isn't reading the manual enough to understand? > [Harbour] Developers are discussing these points and lower level functions > are in place. > Probably within next week or so, they will come up with Xbase++ compatible > Singnal() objects. > >> and last but not least : what about DualCore with 4 or more CPU ? > > [Harbour] Supports it. You're talking nonsense. There is no (real) MT without multiple CPUs/cores. I would suggest you to get a book on multithreading in general before arguing on the topic. This is a good start: http://www.amazon.com/Art-Multiprocessor-Programming-Maurice-Herlihy/dp/0123705916/ref=pd_bbs_1?ie=UTF8&s=books&qid=1221898149&sr=8-1 Said all this, if a standard is getting established, it may be sensed to follow it WITHOUT imposing any limitation. In example, areas and variables may be made thread-local by default, while the keyword SHARED in declaration would make them publically visible to all threads. In this way, MT programs written in XBase++/Harbour would be immediately portable to XHarbour, which would still provide the feature of having shared variables, and areas, across threads. Giancarlo. P.S. There IS ground in arguing that an established standard should be followed OR that one method may lead to provide more performance at VM level than the other; so, there IS ground in suggesting that XHarbour should be like XBase++ in this aspect. Just none of your contribute to this discussion was in that direction; they're plainly nonsense. On Fri, 19 Sep 2008 20:41:37 -0700 (PDT) Pritpal Bedi <[EMAIL PROTECTED]> wrote: > Message-ID: <[EMAIL PROTECTED]> > > > And this is my reply to the previous post: > > > Jimmy > > >> :-) Which means that you cannot work on the same area from different > >> threads. > > > > you can use Xbase++ ZeroSpace() to switch Workspace if you want ... > > Absolutely right. Today Przemek has committed exactly same behaviour as of > Xbase++ > > **************************** > 2008-09-20 00:42 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > + harbour/source/rdd/wadetach.c > + added .prg functions: > hb_waDetach( [<nWorkArea>|<cAlias>], [<xCargo>] ) -> <lSuccess> > hb_waRequest( [<cAlias>], [<lFreeArea>], [<@xCargo>], [<lWait>] ) > -> <lSuccess> > The first one detach workarea from current thread and move it > to special hidden holder. Before detaching all relations (parent > and child) to detached workarea are cleared. > The second one restores area from the holder and attach it > to calling thread. > + added xBase++ compatible functions DbRelease() / DbRequest() > xBase++ users please test. If possible please also check what xBase++ > does with relations and active RLOCKs/FLOCK on released WA. > **************************** > > > ... what happend if you use different Threads and call external DLL > > where you have to use Stacks and Pointer ? > > > > This is interesting point. I will forward it to Harbour NG. > > > i do not know how MT model in xharbour work, but we had that Discussion > > in Xbase++ long time ago. You might call it a limitation but i do not feel > > limited by Xbase++ MT when i have the Security that they are realy > > Thread - "Safe" > > > > Exactly my view point. MT looses all its glory if it is not self contained. > > > i can not see a sense to work from 2 Thread to same WorkspaceArea > > on same DBF ... what happen if 1 Thread fail (and Record ist locked) ? > > > > I confirm. > > > same with PUBLIC and PRIVATE, which you can accsess from each > > Thread in Xbase++ ... but did you "modify" those Memvar at runtime ? > > [Harbour] Even STATICS can be declared thread safe with keyword > THREAD STATIC. This feature is not available in Xbase++ also, correct > me if I am wrong because I left development on Xbase++ long back. > > > i do not know how MT model in xharbour "talk" between Thread ? > > how to "signal" others Threads ? > > how to send Events to other Thread ? > > how to access Class Var from other Threads ? > > [Harbour] Developers are discussing these points and lower level functions > are in place. > Probably within next week or so, they will come up with Xbase++ compatible > Singnal() objects. > > > and last but not least : what about DualCore with 4 or more CPU ? > > [Harbour] Supports it. > > > i agree that Xbase+ seem to open new connection in each WorkspaceArea(). > > it woud be nice to have a "build-in" Cache to "mirror" next Connection as > > "vitural" DBF :) > > [Harbour] Przemek has shown intererst in this area as he refers it as > "Cloning" > the WAs. I hope it will be in place soon. > > Regards > Pritpal Bedi > > > -- > View this message in context: > http://www.nabble.com/MT-Modal---Harbour-vs-xHarbour-tp19582273p19582385.html > Sent from the Harbour - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
