Przemyslaw Czerpak-2 wrote: > > Nice to see your messages again. >
I am always lurking out here. Nice to see you are still aggressively involved in Harbour. I assume you are still disconnected from xHarbour based upon our communications a year ago (or so). Przemyslaw Czerpak-2 wrote: > > Interesting. Such weak scalability is usually result of intensive > critical section usage. In the last two years are invest a lot of time > to eliminate such code so now only few small elements are covered by > critical sections what should not reduce the performance on real multi > CPU machines. > I am only an external observer of the runtime. I do not look at the internals because I have no control over them. What would I do with any discovery? Nevertheless, I think Xbase++ is hindered by 'intensive critical sections'. I think they are driven to this because GC and memory compaction is performed on an independent thread without halting the application. I think they use lightweight synchronization techniques that are facilitated by single processor core affinity and the GC works continuously and incrementally. If I remember the xHarbour source correctly (which I assume is similar to Harbour), it pauses application threads while GC is operational. Przemyslaw Czerpak-2 wrote: > > The ADS RDD will have to be updated for MT mode. Not all things are safe. > Especially there is a problem with some global settings passing to ADS > library like _SET_DELETED. So far I haven't checked if ACE has some > additional support for MT programs so I cannot say too much about. > Anyhow this I'd like to leave for ADSRDD developers/users. I do not use > it. > ACE is natively MT. It supports one outstanding request per DBS connection and serializes requests from multiple threads that are sharing a connection. Przemyslaw Czerpak-2 wrote: > > Harbour does not have such protection. I was thinking about it but it has > to cost extremely much. On some architecture it will be real performance > killer if we will call OS synchronization function. It will be necessary > to use some assembler hacks to reduce it. Such elements will have to be > discuss here. Give full complex item integrity protection with the cost > of performance. I'm afraid that it will be hard to agree common decision. > People familiar with MT programming will prefer missing protection and > better performance because for all shared variables it's always necessary > to add own protection and they used to make it correctly. But people who > begins their adventure with MT programing each additional protection will > be welcome. Anyhow for the answer we will have to wait for users' > experiences > after working with current code. > Maybe we will chose some middle solution. F.e. synchronization reference > item so user will be able to declare variable as automatically synced in > source code or at RT by some function, f.e. hb_autoSyncVar( @var, <lOnOff> > ) > As I stated above, I think the variable access synchronization is driven by the parallel execution GC design more than providing protection to discrete variables. As you stated earlier, entire expressions would need to be atomic for most MT applications to be accurate. In reality, .PRG level MT support in Xbase++ is limited to SYNC methods of classes. Przemyslaw Czerpak-2 wrote: > > I will have to think about it longer to give you an answer. Now I cannot > say how it will work with long references chains when some of references > are in thread local heap and some other in thread global. Moving complex > item from local to global thread also does not look easy. F.e. some > subarrays > can still be accessible by local variables so we will have to mark all > complex > item nodes (it will benecesary to add circularity detection) that they > belongs > to common heap. Otherwise they will be still accessible without protection > by > other thread local variables. I also see some other problems which will > have > to be resolved. Now I do not find it as easy to implement solution. > I did not want to imply that it would be easy. IMO, the complexity works against the proposal. I think the best case examples to study for insight are the Java and .NET runtimes since they experience the exact same issues AND have had significant resources to develop their solutions. However, their solutions may very well require those significant resources which are unavailable to the Harbour project. Przemyslaw Czerpak-2 wrote: > > But I have one question. AFAIR in xbase++ the active locks set on executed > SYNC methods are removed when thread executes oSignal:wait. Then they are > restored - locked again. Maybe I do not understand some conditions but for > me it's sth what can create deadlock if signaled thread have to restore > more then one lock and it's out of user control. Is documented what > xbase++ > does in such case? > My interpretation of the documentation (which is not backed by actual experience) is that the locks are not removed. Instead, I believe that locks held by a waiting thread are ignored by other threads AND the waiting thread is blocked from CPU scheduling while another thread is executing a SYNC method to which it 'interrupted' the lock AND the lock ownership is changed/restored to the other thread while the SYNC method is active. Hope this helps. Rodd Graham -- View this message in context: http://www.nabble.com/A-few-questions-about-MT-tp19555409p19695418.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
