Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
The reason is that the cache coherency algorithms don't scale. This again is a software problem. If the task to do allows it the software needs to be written in a way that the cache coherency is not disturbed. BTW all super-computers feature thousands of CPUs, but of course this is not simple SMP. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information notcompatible withFPClocale variables
Very well said ;-) . Then on the other said to play the Diablo's advocate and support what our opponents have said in the super-computers the tasks are handled by the operating system. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Michael Schnell [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, July 31, 2008 12:31 AM Subject: Re: [fpc-devel] Russian locale information notcompatible withFPClocale variables If the task to do allows it the software needs to be written in a way that the cache coherency is not disturbed. BTW all super-computers feature thousands of CPUs, but of course this is not simple SMP. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale informationnotcompatible withFPClocale variables
Hmm... correction, they probably are also using ADA for that ;-) . With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Boian Mitov [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, July 31, 2008 12:35 AM Subject: Re: [fpc-devel] Russian locale informationnotcompatible withFPClocale variables Very well said ;-) . Then on the other said to play the Diablo's advocate and support what our opponents have said in the super-computers the tasks are handled by the operating system. With best regards, Boian Mitov ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale informationnotcompatible withFPClocale variables
Original-Nachricht Hmm... correction, they probably are also using ADA for that ;-) . No, Fortran (I was told, it ain't FORTRAN anymore, modern compilers can handle lower case). Vinzent. P.S. The American Dentist's Association has nothing to do with that... did you mean Ada (Byron Lovelace) as in (Blaise) Pascal? ;) -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Op Thu, 31 Jul 2008, schreef Michael Schnell: The reason is that the cache coherency algorithms don't scale. This again is a software problem. Cache coherency algorithms are implemented in hardware. If the task to do allows it the software needs to be written in a way that the cache coherency is not disturbed. Easier said than done, because threading always involves multiple cores operating in the same address space, which means the cores need to communicate which core has which page in cache. BTW all super-computers feature thousands of CPUs, but of course this is not simple SMP. Like I said, the HPC world did move to distributed memory with message passing years ago and is not using threading. Threading simply didn't scale enough. Daniël ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale informationnotcompatible withFPClocalevariables
Stupid me, to 20 years ago when I studied Fortran 77, I thought it was obsolete :-) I hope they at least have loops now, and who knows, it may even support Hmm Hmm... recursion :-D . With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Vinzent Höfler [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, July 31, 2008 12:54 AM Subject: Re: [fpc-devel] Russian locale informationnotcompatible withFPClocalevariables Original-Nachricht No, Fortran (I was told, it ain't FORTRAN anymore, modern compilers can handle lower case). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Daniël Mantione wrote: Easier said than done, because threading always involves multiple cores operating in the same address space, which means the cores need to communicate which core has which page in cache. They don't care about pages. They only care when writing to shared memory (to keep other caches consistent). This is on cache line level, e.g. 32 bytes for PPC usually, 128 bytes on Intel. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale informationnotcompatible withFPClocalevariables
Op Thu, 31 Jul 2008, schreef Boian Mitov: Stupid me, to 20 years ago when I studied Fortran 77, I thought it was obsolete :-) I hope they at least have loops now, and who knows, it may even support Hmm Hmm... recursion :-D . No, Fortran is still in big use, and yes it is obsolete. However, it has some features people like, like local arrays that are dimensioned at procedure call time. I'm playing with the idea of implementing such a feature in FPC, like: procedure x(const s:integer); var a:array[0..s] of byte; ... or something. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatiblewithFPClocale variables
This discussion is fun, but we probably should leave this to Intel, Sony, AMD and Sun to fight. Personally I am surprised that we are on the verge of having systems with 32 cores, be it that some are half cores (The Hyper Threading ones). Having 32 cores even if you never get more, already starts to make a statement in support for the need of multithreaded applications, and probably compilers better utilizing the cores. Then again maybe it is just a hype, but if so it has been continuing for few years already, and it only seems to grow in strength. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Micha Nelissen [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, July 31, 2008 1:04 AM Subject: Re: [fpc-devel] Russian locale information not compatiblewithFPClocale variables They don't care about pages. They only care when writing to shared memory (to keep other caches consistent). This is on cache line level, e.g. 32 bytes for PPC usually, 128 bytes on Intel. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale informationnotcompatiblewithFPClocalevariables
It had some feature I liked including direct Complex number support. Variable stack arrays are also available in C99 but not in the C++ standard, and as the best of my knowledge there are no plans to add them in the 200X ANSI revision :-( . So far Delphi has been doing fine with the classical variable arrays and SetLength ;-) . With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Daniël Mantione [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, July 31, 2008 1:10 AM Subject: Re: [fpc-devel] Russian locale informationnotcompatiblewithFPClocalevariables No, Fortran is still in big use, and yes it is obsolete. However, it has some features people like, like local arrays that are dimensioned at procedure call time. I'm playing with the idea of implementing such a feature in FPC, like: ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale informationnotcompatible withFPClocalevariables
Stupid me, to 20 years ago when I studied Fortran 77, I thought it was obsolete :-) I hope they at least have loops now, and who knows, it may even support Hmm Hmm... recursion :-D . As far as I know it does. Lemme check ... http://en.wikipedia.org/wiki/Fortran ... yes, since Fortran90, it seems. But we're getting dangerously off-topic now... Vinzent. -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale informationnotcompatible withFPClocalevariables
Op Thu, 31 Jul 2008, schreef Boian Mitov: Stupid me, to 20 years ago when I studied Fortran 77, I thought it was obsolete :-) I hope they at least have loops now, and who knows, it may even support Hmm Hmm... recursion :-D . No, Fortran is still in big use, and yes it is obsolete. However, it has some features people like, like local arrays that are dimensioned at procedure call time. Ada and C99 have that. Scripting languages anyway... I think the main feature of Fortran is the heavily optimzing compiler. ;) I'm playing with the idea of implementing such a feature in FPC, like: procedure x(const s:integer); var a:array[0..s] of byte; ... or something. Hmm. |var a : array of byte; | |SetLength (a, s); should do? Vinzent. -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale informationnotcompatible withFPClocalevariables
Op Thu, 31 Jul 2008, schreef Vinzent Höfler: Op Thu, 31 Jul 2008, schreef Boian Mitov: Stupid me, to 20 years ago when I studied Fortran 77, I thought it was obsolete :-) I hope they at least have loops now, and who knows, it may even support Hmm Hmm... recursion :-D . No, Fortran is still in big use, and yes it is obsolete. However, it has some features people like, like local arrays that are dimensioned at procedure call time. Ada and C99 have that. Scripting languages anyway... I think the main feature of Fortran is the heavily optimzing compiler. ;) With C you have exactly the same compiler. True, it is a reason against Pascal, but does not explain the popularity of Fortran. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale informationnotcompatiblewithFPClocalevariables
Thank you! I agree. To summaries my opinion: 1. Massive multicores are slowly becoming a reality. 2. The modern compilers do little to support them aside from some library support. 3. The need for such support is not urgent, and probably will not be for at least 1-2 more years, but the demand will start to rise. 4. The best approach is to keep an eye on what the other compiler developers are doing, and try to follow the proven path ;-) . 5. In the mean time any good developer an utilize the existing tools and design true multithreading architectures. We have enough tools for that (Well maybe with the exception of a fast Multi Read Single Write implementation, but the life is never easy ;-) ) With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Vinzent Höfler [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, July 31, 2008 1:23 AM Subject: Re: [fpc-devel] Russian locale informationnotcompatiblewithFPClocalevariables As far as I know it does. Lemme check ... http://en.wikipedia.org/wiki/Fortran ... yes, since Fortran90, it seems. But we're getting dangerously off-topic now... Vinzent. -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
On Wed, Jul 30, 2008 at 6:05 PM, Daniël Mantione [EMAIL PROTECTED] wrote: ...because all characters that need upper/lower casing are in the BMP. Likewise, all possible thousand separators are in the BMP, so you don't need to bother with that either. Ah, that's so true. :-) I'm starting to like the idea of UTF-16 more and more compared to UTF-8. UTF-8 is a lot more work. If so, it would same me a lot of time implementing them myself. What would Pos, Length, Copy etc return? This would be the same behaviour as with widestrings. RTL routines are dump, smarter ones should go in sysutils. OK thanks. I'll start creating unit tests for some of these basic functions so I can solidify my understanding and expected behaviour of widestrings and UTF-16. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPClocale variables
Eg only allow the parallel or async keyword (I personally do not care which) on an otherwise normal procedure and then another procedure/keyword isfinished(x)? In fact Oxygen does also support the parallel keyword/paradigm that works very similar to what you suggest: http://wiki.remobjects.com/wiki/Parallel_Loops They only seem to allow the parallel keyword for loops: for parallel i: Integer := 0 to 10 do ... But why not (additionally) do parallel procedure x(a: integer); begin ... end; Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
On Thu, 31 Jul 2008 11:02:28 +0200 Florian Klaempfl [EMAIL PROTECTED] wrote: Before we discuss endless about useless stuff, I'll make a proposal for a first addition: support of the synchronized keyword. It does no more than protecting a procedure automatically by a critical section so only one thread can enter it. But I want to extend it. First, it can be applied also to classes and object: tmyclass = class(...) synchronized This means that all classes synchronize against one critical section. Do you mean one global crit sect per class (and descendants) or one global crit sect for all classes? Further, it allows an additional symbol to be given procedure p;synchronized mycriticialsection; it must be of the type System.TRTLCriticalSection and the procedure will be synchronized against this critical section. Will this also allowed for methods? Besides saving the typing of endless try ... finally statements and the initialiation of the unnamed critical sections, it creates also slightly better code because the LeaveCriticalSection call can be inside the implicit exception frame which is created anyways. Any suggestions about doing it better? BTW: I'll ignore comments like nobody needs this, I need it :) I like it. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Mattias Gaertner schrieb: On Thu, 31 Jul 2008 11:02:28 +0200 Florian Klaempfl [EMAIL PROTECTED] wrote: Before we discuss endless about useless stuff, I'll make a proposal for a first addition: support of the synchronized keyword. It does no more than protecting a procedure automatically by a critical section so only one thread can enter it. But I want to extend it. First, it can be applied also to classes and object: tmyclass = class(...) synchronized This means that all classes synchronize against one critical section. Do you mean one global crit sect per class (and descendants) Per class. The question is if it's possible to do this per class instance too. or one global crit sect for all classes? Further, it allows an additional symbol to be given procedure p;synchronized mycriticialsection; it must be of the type System.TRTLCriticalSection and the procedure will be synchronized against this critical section. Will this also allowed for methods? Yes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale informationnotcompatiblewithFPClocalevariables
4. The best approach is to keep an eye on what the other compiler developers are doing, and try to follow the proven path ;-) . That is why I suggest to take a look at .NET (and the pascal implementation of same (not Codegear's :) ), even if implementing the paradigms without a framework (which in fact on that behalf is something nothing but an external RTL). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russianlocale informationnotcompatiblewithFPClocalevariables
Just to make it clear. C++ is very good in conceptual implementation, but lacks any support for concept declarations as example, and there is no error checking :-( . I have done some STL compliant containers in the past and validating the concept was a nightmare :-( . With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Boian Mitov [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, July 31, 2008 2:32 AM Subject: Re: [fpc-devel] Russianlocale informationnotcompatiblewithFPClocalevariables Personally I think C++ is just not very good in it, but Pascal simply can't do it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel]Russian locale informationnotcompatiblewithFPClocalevariables
Michael, CodeGear has not yet started working on the new features. I am not allowed however to mention what they plan to do, even if I know ;-) . With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Michael Schnell [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, July 31, 2008 2:36 AM Subject: Re: [fpc-devel]Russian locale informationnotcompatiblewithFPClocalevariables That is why I suggest to take a look at .NET (and the pascal implementation of same (not Codegear's :) ), even if implementing the paradigms without a framework (which in fact on that behalf is something nothing but an external RTL). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RussianlocaleinformationnotcompatiblewithFPClocalevariables
Generics can't implement conceptual programming. As example for conceptual programming you can perform the same algorithm on simple arrays such as char Array[ 1000 ] as you can on any STL compliant container. The integrator concept is implemented different way but since it is concept as Sort algorithm will work. Generics do not allow that. With generics you can do Generics based programming but not concept based programming. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Mattias Gaertner [EMAIL PROTECTED] To: fpc-devel@lists.freepascal.org Sent: Thursday, July 31, 2008 2:57 AM Subject: Re: [fpc-devel] RussianlocaleinformationnotcompatiblewithFPClocalevariables This was added recently: See language reference 'generics' (chapter 8 in pdf). Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Per class. The question is if it's possible to do this per class instance too. To me Per class does not seem appropriate at all. Per instance in fact seems to make sense. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RussianlocaleinformationnotcompatiblewithFPClocalevariables
I mean the iterator concept... Gee... a long night ;-) With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Boian Mitov [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, July 31, 2008 3:00 AM Subject: Re: [fpc-devel] RussianlocaleinformationnotcompatiblewithFPClocalevariables integrator concept is implemented different way but since it is concept as ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Michael Schnell schrieb: Now you suggest that all procedures an instance of this kind of class are protected and thus thread-safe by definition. They aren't but it makes things easier. Just look at the linux kernel: it's smp support started also with BKL: the Big Kernel Lock ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Micha Nelissen schrieb: Florian Klaempfl wrote: Further, it allows an additional symbol to be given procedure p;synchronized mycriticialsection; Any suggestions about doing it better? How to avoid deadlocks? Indeed, I'am open to any suggestions :) Just an idea: maybe a global call tree analysis with a call tree attributed with critical section information can find potential deadlocks? If a synchronized class is calling another synchronized class ... :-S. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Florian Klaempfl wrote: Michael Schnell schrieb: Now you suggest that all procedures an instance of this kind of class are protected and thus thread-safe by definition. They aren't but it makes things easier. Just look at the linux kernel: it's smp support started also with BKL: the Big Kernel Lock That's not so good example since now it's almost gone. That suggests this synchronized keyword would be deprecated in a few years as well ;-) Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
synchronous class [Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables]
IMHO per class may create some problems? but maybe I am just overlooking something? TBar =class( TFoo ) end synchronized class; Let's say TFoo was declared in another unit, and TFoo was not declared Synchronized. Then TFoo code can be entered by anyone at any time. Even if a thread is in TBar. How would one make sure, that a base class, knows about all classes that inherit from it? Neither can you say the baseclass must also be synchronous class, because ultimately there always is TObject. and TObject does not want to be Synchronous class, or all Create/destroy would be in critical sections? It my be possible to work around, this, but it would probably create a ig overhead, as every method one very class would have to perform checks at runtime. Similar for instance wide protection. Regards Martin Michael Schnell wrote: Per class. The question is if it's possible to do this per class instance too. To me Per class does not seem appropriate at all. Per instance in fact seems to make sense. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Just look at the linux kernel: it's smp support started also with BKL: the Big Kernel Lock And since that time they are working to get rid of it. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: synchronous class [Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables]
Martin Friebe wrote: IMHO per class may create some problems? but maybe I am just overlooking something? TBar =class( TFoo ) end synchronized class; Let's say TFoo was declared in another unit, and TFoo was not declared Synchronized. Then TFoo code can be entered by anyone at any time. Even if a thread is in TBar. How would one make sure, that a base class, knows about all classes that inherit from it? Why does it need to know? Base classes can't access the fields of inherited classes anyway. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Micha Nelissen schrieb: Florian Klaempfl wrote: Michael Schnell schrieb: Now you suggest that all procedures an instance of this kind of class are protected and thus thread-safe by definition. They aren't but it makes things easier. Just look at the linux kernel: it's smp support started also with BKL: the Big Kernel Lock That's not so good example since now it's almost gone. That suggests this synchronized keyword would be deprecated in a few years as well ;-) Come one, it's not that hard to understand :): synchronized might allow the same way of working: first, you work with big locks, later to add more fine granulated ones. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Per instance would mean to need an algorithm to automatically define a new Mutex when creating an instance. So maybe the TSynchronizedObject that might be the parent of all class(...) synchronized will define a TSynchronizedObject.Create that creates a Class-common or a system wide Mutex, while the create in a child class can modify this behavior to the use of an instance variable as the Mutex to have a per-instance protection. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
Original-Nachricht Von: Florian Klaempfl [EMAIL PROTECTED] OTOH, it's looks about the same as in Java and even Java now has explicit Locks, because synchronized simply isn't efficient nor flexible enough... ;) Since I don't use java, what's the difference of locks? More control over where, when and how parts of the code must be locked. So you can do finer grained, and thus usually more efficient, locking. Just like the classic approach. ;) A good example might be the multiplereader-singlewriter locks. Doing that with synchronized can be really inefficient if a protected data structure gets written seldom, but read often. That's BTW why I like the Ada approach of the protected object much more: protected Buffer is entry Put (I : in Integer); -- Potentially blocking (if internal queue is full) entry Get (I : out Integer); -- Potentially blocking (if internal queue is empty) procedure Write_Something; -- May write to the object, so can only be entered once, but never waits. function Read_Something; -- Only reads, so this subroutine can be entered several times. Never waits. end Buffer; The basic idea is: entries may block (on guards = condition variables), procedures can only be entered once at a time, because they may change the object's state and functions can be entered concurrently. Of course, if a write operation currently occurs (procedure call), no read operation (function call) is allowed during that time. In that way, the whole data structure and operations on it are relatively well defined even in temporal terms. Vinzent. -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel] Russianlocale information not compatible withFPClocale variables
Funny thing, we went trough the same evolution with our libraries over the years :-D . We used to have a single lock for each connection chain. Now we have individual locks for each component and each OpenWire pin, and it works much better and faster. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Florian Klaempfl [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, July 31, 2008 3:23 AM Subject: Re: Multi threading support was Re: [fpc-devel] Russianlocale information not compatible withFPClocale variables Come one, it's not that hard to understand :): synchronized might allow the same way of working: first, you work with big locks, later to add more fine granulated ones. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel] Russianlocale information not compatible withFPClocale variables
My personal experience so far has confirmed this. Reducing the scope and the duration of the locks, and allocating individual locks to individual resources increases the performance and oddly reduces the danger of deadlocks. I used to spend days tracking deadlock conditions. Hardly nowadays after allocating individual locks per critical resource, and carefully defining the scope of each lock. Having single centralized lock is hardly a good approach. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Florian Klaempfl [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, July 31, 2008 3:23 AM Subject: Re: Multi threading support was Re: [fpc-devel] Russianlocale information not compatible withFPClocale variables Come one, it's not that hard to understand :): synchronized might allow the same way of working: first, you work with big locks, later to add more fine granulated ones. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
Original-Nachricht Von: Michael Schnell [EMAIL PROTECTED] OTOH, it's looks about the same as in Java and even Java now has explicit Locks, because synchronized simply isn't efficient I suppose if using Futex (in Linux) or an implementation of a user space Mutex in the RTL (using a bus locked read-modify write instruction and do a system call only when the resource is taken by another thread) needs close to no CPU time. Yes, but often the question is not how long the *locking* operation takes, but rather how long the *locked* operation takes. Vinzent. -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
Yes, but often the question is not how long the *locking* operation takes, but rather how long the *locked* operation takes. Of course you are right, but this is not a compiler / Library thing but depends on the design of the user program. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
Original-Nachricht Von: Michael Schnell [EMAIL PROTECTED] Yes, but often the question is not how long the *locking* operation takes, but rather how long the *locked* operation takes. Of course you are right, but this is not a compiler / Library thing but depends on the design of the user program. Of course, but sometimes it's simply not feasible to split the algorithm into several synchronized subroutines. Especially when multiple locks are involved. Vinzent. -- GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
Hello,
Am 31.07.2008 um 11:56 schrieb Florian Klaempfl:
Vinzent Höfler schrieb:
Original-Nachricht ---
OTOH, it's looks about the same as in Java and even Java now has
explicit Locks, because synchronized simply isn't efficient nor
flexible enough... ;)
Since I don't use java, what's the difference to locks?
In practice imo not too much, synchronized is just a convenience
functionality, exactly like the one you proposed.
In short the difference:
Java always locks on monitors i.e. guards which are available for any
object; Pre 1.5 the only way to lock was using some syntax additions.
The syntax allows per method (class or instance) or per block scope,
i.e.
synchronized void doSomething() { ... } // method level: monitor
object is either this or this.class object
void doSomething() {
...
synchronized (monitor) { // on block level; monitor object is
this if not specified otherwise the given object
}
...
}
With 1.5 they added a Lock interface which provides the usual lock
()/trylock()/unlock() methods which should be self-explaining.
This for example allows interlocked locks if required
lock1.lock();
...
lock2.lock();
...
lock1.unlock();
...
lock2.unlock();
Hth,
Thomas___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
This is an idea using automatic cleanup of interfaces:
procedure foo; - lock
begin
synchronize(cs);
[...]
end; - unlock
or
procedure foo; - lock
begin
with synchronize(cs) do - lock
begin
[...]
end; - unlock
end;
{ TLock }
type
TLock = class(TInterfacedObject)
private
FCriticalSection: TCriticalSection;
public
constructor Create(cs: TCriticalSection); virtual;
destructor Destroy; override;
end;
constructor TLock.Create(cs: TCriticalSection);
begin
FCriticalSection := cs;
cs.Acquire;
end;
destructor TLock.Destroy;
begin
FCriticalSection.Release;
inherited;
end;
function synchronize(cs: TCriticalSection): IUnknown;
begin
Result := TLock.Create(cs);
end;
2008/7/31 tom_at_work [EMAIL PROTECTED]
Hello,
Am 31.07.2008 um 11:56 schrieb Florian Klaempfl:
Vinzent Höfler schrieb:
Original-Nachricht ---
OTOH, it's looks about the same as in Java and even Java now has
explicit Locks, because synchronized simply isn't efficient nor
flexible enough... ;)
Since I don't use java, what's the difference to locks?
In practice imo not too much, synchronized is just a convenience
functionality, exactly like the one you proposed.
In short the difference:
Java always locks on monitors i.e. guards which are available for any
object; Pre 1.5 the only way to lock was using some syntax additions. The
syntax allows per method (class or instance) or per block scope, i.e.
synchronized void doSomething() { ... } // method level: monitor object is
either this or this.class object
void doSomething() {
...
synchronized (monitor) { // on block level; monitor object is this if
not specified otherwise the given object
}
...
}
With 1.5 they added a Lock interface which provides the usual
lock()/trylock()/unlock() methods which should be self-explaining.
This for example allows interlocked locks if required
lock1.lock();
...
lock2.lock();
...
lock1.unlock();
...
lock2.unlock();
Hth,
Thomas___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
Hmm... it looks almost one to one copy from our code in Version 4.0 of our
libraries ;-) . Are you one of our customers, or you have simply come with the
same idea as us?
With best regards,
Boian Mitov
Mitov Software
http://www.mitov.com
- Original Message -
From: Henri Gourvest
To: FPC developers' list
Sent: Thursday, July 31, 2008 5:57 AM
Subject: Re: [fpc-devel] Re: Multi threading support
This is an idea using automatic cleanup of interfaces:
procedure foo; - lock
begin
synchronize(cs);
[...]
end; - unlock
or
procedure foo; - lock
begin
with synchronize(cs) do - lock
begin
[...]
end; - unlock
end;
{ TLock }
type
TLock = class(TInterfacedObject)
private
FCriticalSection: TCriticalSection;
public
constructor Create(cs: TCriticalSection); virtual;
destructor Destroy; override;
end;
constructor TLock.Create(cs: TCriticalSection);
begin
FCriticalSection := cs;
cs.Acquire;
end;
destructor TLock.Destroy;
begin
FCriticalSection.Release;
inherited;
end;
function synchronize(cs: TCriticalSection): IUnknown;
begin
Result := TLock.Create(cs);
end;
2008/7/31 tom_at_work [EMAIL PROTECTED]
Hello,
Am 31.07.2008 um 11:56 schrieb Florian Klaempfl:
Vinzent Höfler schrieb:
Original-Nachricht ---
OTOH, it's looks about the same as in Java and even Java now has
explicit Locks, because synchronized simply isn't efficient nor
flexible enough... ;)
Since I don't use java, what's the difference to locks?
In practice imo not too much, synchronized is just a convenience
functionality, exactly like the one you proposed.
In short the difference:
Java always locks on monitors i.e. guards which are available for any
object; Pre 1.5 the only way to lock was using some syntax additions. The
syntax allows per method (class or instance) or per block scope, i.e.
synchronized void doSomething() { ... } // method level: monitor object is
either this or this.class object
void doSomething() {
...
synchronized (monitor) { // on block level; monitor object is this if
not specified otherwise the given object
}
...
}
With 1.5 they added a Lock interface which provides the usual
lock()/trylock()/unlock() methods which should be self-explaining.
This for example allows interlocked locks if required
lock1.lock();
...
lock2.lock();
...
lock1.unlock();
...
lock2.unlock();
Hth,
Thomas___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
--
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
BTW: As it was discussed a while ago this does not work so well with Lazarus due to some optimizations they do with when a reference is decremented. With some tricks however it seems that we are on our way to get it to work under Lazarus as well. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Boian Mitov To: FPC developers' list Sent: Thursday, July 31, 2008 5:59 AM Subject: Re: [fpc-devel] Re: Multi threading support Hmm... it looks almost one to one copy from our code in Version 4.0 of our libraries ;-) . Are you one of our customers, or you have simply come with the same idea as us? With best regards, Boian Mitov Mitov Software http://www.mitov.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
sorry, it is also my idea :D
I recently written a new light db interface for firebird, to simplify
queries
and auto commit transactions (context)
with pool.GetConnection.newContext do - start transaction
Execute(newCommand('DELETE FROM COUNTRY WHERE COUNTRY = ?'), [1]);
- commit/rollback transaction
I also remember MS DirectShow SDK (to write codecs) use an object allocated
in the stack to syncronyse critical sections, it look like our trick with
the interface
2008/7/31 Boian Mitov [EMAIL PROTECTED]
BTW: As it was discussed a while ago this does not work so well with
Lazarus due to some optimizations they do with when a reference is
decremented. With some tricks however it seems that we are on our way to get
it to work under Lazarus as well.
With best regards,
Boian Mitov
Mitov Software
http://www.mitov.com
- Original Message -
*From:* Boian Mitov [EMAIL PROTECTED]
*To:* FPC developers' list fpc-devel@lists.freepascal.org
*Sent:* Thursday, July 31, 2008 5:59 AM
*Subject:* Re: [fpc-devel] Re: Multi threading support
Hmm... it looks almost one to one copy from our code in Version 4.0 of
our libraries ;-) . Are you one of our customers, or you have simply come
with the same idea as us?
With best regards,
Boian Mitov
Mitov Software
http://www.mitov.com
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
In C++ this is a classical block enclosement. I have used for few years in
Delphi with interfaces. I was badly surprised that there are some issues when
you try to use it in Lazarus, but with some code changes I think I have worked
it around, and so far it seems to work in Lazarus too, just with some
limitations ( Destructors as example ).
In Delphi however there is a different problem. In C++ the order of destruction
will be exactly opposite of the order of creation. There is no such guarantee
in Delphi, so having 2 locks declared leads to problems due to wrong order of
destruction. This is yet another example where C++ simply shines ;-) .
With best regards,
Boian Mitov
Mitov Software
http://www.mitov.com
- Original Message -
From: Henri Gourvest
To: FPC developers' list
Sent: Thursday, July 31, 2008 6:29 AM
Subject: Re: [fpc-devel] Re: Multi threading support
sorry, it is also my idea :D
I recently written a new light db interface for firebird, to simplify queries
and auto commit transactions (context)
with pool.GetConnection.newContext do - start transaction
Execute(newCommand('DELETE FROM COUNTRY WHERE COUNTRY = ?'), [1]);
- commit/rollback transaction
I also remember MS DirectShow SDK (to write codecs) use an object allocated
in the stack to syncronyse critical sections, it look like our trick with the
interface
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RussianlocaleinformationnotcompatiblewithFPClocalevariables
Boian Mitov wrote / napísal(a): Generics can't implement conceptual programming. As example for conceptual programming you can perform the same algorithm on simple arrays such as char Array[ 1000 ] as you can on any STL compliant container. The integrator concept is implemented different way but since it is concept as Sort algorithm will work. Generics do not allow that. With generics you can do Generics based programming but not concept based programming. With best regards, Boian Mitov Mitov Software http://www.mitov.com I also thought you ment generics. Please provide (for example C++) code example, I still don't get what you mean. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
On Thu, Jul 31, 2008 at 2:57 PM, Henri Gourvest [EMAIL PROTECTED] wrote: This is an idea using automatic cleanup of interfaces: That is so cleaver! :) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RussianlocaleinformationnotcompatiblewithFPClocalevariables
Sort for example:
It can work with C type array:
int a[7] = {23, 1, 33, -20, 6, 6, 9};
sort(a, a+7);
or it can work with a container such as linked list:
listSomething v1;
sort(v1.begin(), v1.end());
With best regards,
Boian Mitov
Mitov Software
http://www.mitov.com
- Original Message -
From: Ales Katona [EMAIL PROTECTED]
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Thursday, July 31, 2008 7:11 AM
Subject: Re: [fpc-devel]
RussianlocaleinformationnotcompatiblewithFPClocalevariables
Boian Mitov wrote / napísal(a):
Generics can't implement conceptual programming. As example for
conceptual programming you can perform the same algorithm on simple
arrays such as char Array[ 1000 ] as you can on any STL compliant
container. The integrator concept is implemented different way but since
it is concept as Sort algorithm will work. Generics do not allow that.
With generics you can do Generics based programming but not concept based
programming.
With best regards,
Boian Mitov
Mitov Software
http://www.mitov.com
I also thought you ment generics.
Please provide (for example C++) code example, I still don't get what you
mean.
Ales
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
On Thu, Jul 31, 2008 at 2:59 PM, Boian Mitov [EMAIL PROTECTED] wrote: Hmm... it looks almost one to one copy from our code in Version 4.0 of our libraries ;-) . Are you one of our customers, or you have simply come with the same idea as us? I'm not Henri, but we did similar setting and auto-restoring mouse cursors in our Delphi applications. I can't imagine why I never thought of using the same idea for critical sections. :-) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
This is what all C++ people do all the time ;-) . In Pascal we have to use the Interface trick. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Graeme Geldenhuys [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, July 31, 2008 7:17 AM Subject: Re: [fpc-devel] Re: Multi threading support That is so cleaver! :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
I actually posted fragments of our code couple of moths ago during the interface decrement discussion. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Graeme Geldenhuys [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, July 31, 2008 7:17 AM Subject: Re: [fpc-devel] Re: Multi threading support On Thu, Jul 31, 2008 at 2:57 PM, Henri Gourvest [EMAIL PROTECTED] wrote: This is an idea using automatic cleanup of interfaces: That is so cleaver! :) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
On Thu, Jul 31, 2008 at 4:21 PM, Boian Mitov [EMAIL PROTECTED] wrote: I actually posted fragments of our code couple of moths ago during the interface decrement discussion. I'll go have a look. :) Thanks to Gmail, I have about 2-3 years of archived mail. I don't use interfaces much (and don't know them very well), but starting to like them more and more. Some solutions are so much more elegant when using interfaces. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Multi threading support
I would make one comment. This type of keyworded critical sections are very nice. To make it really powerfull consider the following declaration: // main function which performs a task, parts of it in parallel procedure BigFunction(ATaskCount: Integer); var fStartEvent: TEvent; // Local function which does parallel work: procedure MyFunction(X: Integer); parallel; begin // typically wait before the main function sets up whatever needs to be set up // - global vars (for BigFunction), etc. fStartEvent.WaitFor; // do something end; var exec_parallel: array[1..ATaskCount] of MyFunction; // The instantiation of ATaskCount parallel functions is done at the declaration of the array // They all hold until the fStartEvent is set in the main functions. // there is a problem - TEvent is a pointer to a class which is not instantiated at // declaration time begin // Set up global data for parallel tasks fStartEvent.SetEvent; // end; This code is loosely borrowed from the way parallel code is done in ADA. It has been a while, but as far as I remember the parallel features in ADA were really elegant and well thought-out. So I would suggest to study carefully the parallel syntax that is intrinsic to ADA. The key thing there were semaphores (critical sections) and arrays of functions which are run in parallel; In order to make the above code work, semaphores and events have to become internal types to Pascal, so they can be instantiated at declaration time. One can also extend the procedure/function syntax by including a WaitFor feature: ... function MyFunc(x: integer): TObject; begin end //the following statement would call the function and then wait until it terminates. case WaitFor(MyFunc(20), time_out) of csSignaled: ... csTimeout: ... end; Best regards to all. Peter Popov On Thu, 31 Jul 2008 04:02:28 -0500, Florian Klaempfl [EMAIL PROTECTED] wrote: Before we discuss endless about useless stuff, I'll make a proposal for a first addition: support of the synchronized keyword. It does no more than protecting a procedure automatically by a critical section so only one thread can enter it. But I want to extend it. First, it can be applied also to classes and object: tmyclass = class(...) synchronized This means that all classes synchronize against one critical section. Further, it allows an additional symbol to be given procedure p;synchronized mycriticialsection; it must be of the type System.TRTLCriticalSection and the procedure will be synchronized against this critical section. Besides saving the typing of endless try ... finally statements and the initialiation of the unnamed critical sections, it creates also slightly better code because the LeaveCriticalSection call can be inside the implicit exception frame which is created anyways. Any suggestions about doing it better? BTW: I'll ignore comments like nobody needs this, I need it :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel -- |***| | | | Peter Popov, | | | | 608L Blocker Bldg. | | Institute for Scientific Computation,| | Texas AM University | | College Station, Texas 77843-3404| |---| | Phone: +1 (979) 458-4644,| | Fax: +1 (979) 845-5827 | | | |***| ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
On Thu, 31 Jul 2008 07:33:16 -0700 Boian Mitov [EMAIL PROTECTED] wrote: You can download the 3.1 version of OpenWire from www.openwire.org . It still uses the MultiReads. I have a new version that compiles under Lazarus, although the editors are not fully functional under GTK in Linux yet. The Checkboxes don't show :-( . Have you reported the bug? I will have to do some more work, but it will be after Delphi 2009 is out. Our main focus is the D2009 release, and Lazarus is on hold for the next 2-3 weeks. I have also included OS independent versions of Mutex, Semaphore Event etc. in the new version. If you want me I can send you the latest sources. They also include the workarounds for the Lazarus reference counting optimization, that used to break the old version. Note: Free Pascal Lazarus. This is a fpc list so please use the correct name. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
- Original Message - From: Mattias Gaertner [EMAIL PROTECTED] To: fpc-devel@lists.freepascal.org Sent: Thursday, July 31, 2008 9:24 AM Subject: Re: [fpc-devel] Re: Multi threading support Have you reported the bug? I have encountered a number of issues, but as I said the Lazarus port will continue after the D2009. I will report all of them ;-) . Note: Free Pascal Lazarus. This is a fpc list so please use the correct name. You are right. This is Free Pascal issue, althoought I have repeetedly been told it is feature ;-D . Ok I have accepted it, and will live with it, so lets not start it over. I am just warnig people I see going in the same path to know how to work around it. With best regards, Boian Mitov Mitov Software http://www.mitov.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RussianlocaleinformationnotcompatiblewithFPClocalevariables
Boian Mitov wrote / napísal(a):
Sort for example:
It can work with C type array:
int a[7] = {23, 1, 33, -20, 6, 6, 9};
sort(a, a+7);
or it can work with a container such as linked list:
listSomething v1;
sort(v1.begin(), v1.end());
With best regards,
Boian Mitov
Mitov Software
http://www.mitov.com
This you mean?
template class RandomAccessIterator
void sort ( RandomAccessIterator first, RandomAccessIterator last );
You can do this with generics. Just use sizeof() to get to next element
and overloaded comparator functions for base types. I don't really see
much new here, it's a bit non-typical generics usage.
Here's a pascal example (OOP, true but that's a current limitation,
afaik generic function should be possible):
program Project1;
{$mode objfpc}{$H+}
type
{ TSorter }
generic TSorterT = class
public
procedure Sort(var First, Last: T);
end;
{ TSorter }
procedure TSorter.Sort(var First, Last: T);
var
x, y: ^T;
z: T;
begin
x := @First;
y := @First;
while x^ Last do begin
while y^ Last do begin
Inc(y);
if x^ y^ then begin
z := x^;
x^ := y^;
y^ := z;
end;
end;
Inc(x);
y := x;
end;
end;
type
TIntSorter = specialize TSorterInteger;
var
s: TIntSorter;
a: array[1..5] of Integer = (5, 4, 3, 2, 1);
i: Integer;
begin
s := TIntSorter.Create;
s.Sort(a[1], a[5]);
for i := 1 to 5 do
Writeln(a[i]);
s.Free;
end.
Ales
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RussianlocaleinformationnotcompatiblewithFPClocalevariables
And the same code will work both with normal array and with object
implementing iterators ?
I am not sure it will.
How I can call your sort for a linked list container instead on array?
Am I missing something or your code works with arrays only.
The STL sort will work with arrays or with STL containers or with any class
that implements the concept (I.E. defines iretator and reference types, and
has iterator generating function etc.)
As the best of my knowledge this is not doable with generics.
C++ is doing it, but there is no validation mechanism aside from just plain
old testing all possible combinations ;-) .
With best regards,
Boian Mitov
Mitov Software
http://www.mitov.com
- Original Message -
From: Ales Katona [EMAIL PROTECTED]
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Thursday, July 31, 2008 9:47 AM
Subject: Re: [fpc-devel]
RussianlocaleinformationnotcompatiblewithFPClocalevariables
Boian Mitov wrote / napísal(a):
Sort for example:
It can work with C type array:
int a[7] = {23, 1, 33, -20, 6, 6, 9};
sort(a, a+7);
or it can work with a container such as linked list:
listSomething v1;
sort(v1.begin(), v1.end());
With best regards,
Boian Mitov
Mitov Software
http://www.mitov.com
This you mean?
template class RandomAccessIterator
void sort ( RandomAccessIterator first, RandomAccessIterator last );
You can do this with generics. Just use sizeof() to get to next element
and overloaded comparator functions for base types. I don't really see
much new here, it's a bit non-typical generics usage.
Here's a pascal example (OOP, true but that's a current limitation, afaik
generic function should be possible):
program Project1;
{$mode objfpc}{$H+}
type
{ TSorter }
generic TSorterT = class
public
procedure Sort(var First, Last: T);
end;
{ TSorter }
procedure TSorter.Sort(var First, Last: T);
var
x, y: ^T;
z: T;
begin
x := @First;
y := @First;
while x^ Last do begin
while y^ Last do begin
Inc(y);
if x^ y^ then begin
z := x^;
x^ := y^;
y^ := z;
end;
end;
Inc(x);
y := x;
end;
end;
type
TIntSorter = specialize TSorterInteger;
var
s: TIntSorter;
a: array[1..5] of Integer = (5, 4, 3, 2, 1);
i: Integer;
begin
s := TIntSorter.Create;
s.Sort(a[1], a[5]);
for i := 1 to 5 do
Writeln(a[i]);
s.Free;
end.
Ales
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RussianlocaleinformationnotcompatiblewithFPClocalevariables
Boian Mitov wrote / napísal(a): And the same code will work both with normal array and with object implementing iterators ? I am not sure it will. How I can call your sort for a linked list container instead on array? Am I missing something or your code works with arrays only. The STL sort will work with arrays or with STL containers or with any class that implements the concept (I.E. defines iretator and reference types, and has iterator generating function etc.) As the best of my knowledge this is not doable with generics. C++ is doing it, but there is no validation mechanism aside from just plain old testing all possible combinations ;-) . With best regards, Boian Mitov Was just a case example. I looked at their code, and it's full of hacks. Practically, they do what I did for basic types (e.g: arrays) with overloads. For classes they do a runtime detection wether it is a container implementing the interface and then procede that way. I'd be doable in pascal too, but I'm still dizzy from looking at their code :) Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RussianlocaleinformationnotcompatiblewithFPClocalevariables
Note that I'm not trying to do a who can piss further thing here. Just saying that IMHO the way C++ does this isn't exactly great. The idea behind it is nice, however apart from pure OOP approach I don't see much choice of how to do this nicely. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RussianlocaleinformationnotcompatiblewithFPClocalevariables
I agree 100%. They are not doing hacks however. I have read some of the books written by them, and they have followed a very strict scientific approach. It really made my head spin at the time ;-) . I have done some STL compliant containers, and yes I hate it, but I was able to do it. There are better languages for conceptual programming, from what I have heard but we seem to be stuck with C++ and OPascal for the moment ;-) . We will do our best with them. Hopefully the next C++ standard will help a bit in this area and will allow concept declarations and validations. The problem is that conceptual programming actually is a totally different concept from the OOP and one of the requirements is that the concept must be hierarchy impendent, so you can make any existing class concept compliant at any level and point. I made existing library STL compliant without touching the hierarchy which I was not allowed to do any way and it worked. All this simply does not seem to be doable with generics. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Ales Katona [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, July 31, 2008 9:59 AM Subject: Re: [fpc-devel] RussianlocaleinformationnotcompatiblewithFPClocalevariables Note that I'm not trying to do a who can piss further thing here. Just saying that IMHO the way C++ does this isn't exactly great. The idea behind it is nice, however apart from pure OOP approach I don't see much choice of how to do this nicely. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
On Thu, 31 Jul 2008 16:22:01 +0200 Graeme Geldenhuys [EMAIL PROTECTED] wrote: On Thu, Jul 31, 2008 at 2:59 PM, Boian Mitov [EMAIL PROTECTED] wrote: Hmm... it looks almost one to one copy from our code in Version 4.0 of our libraries ;-) . Are you one of our customers, or you have simply come with the same idea as us? I'm not Henri, but we did similar setting and auto-restoring mouse cursors in our Delphi applications. I can't imagine why I never thought of using the same idea for critical sections. :-) I think, this sounds like a misuse of interfaces. What you really need is an auto referenced class, that guarantees order and short life time. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
I agree, but we don't have anything like this in Delphi, now do we? With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Mattias Gaertner [EMAIL PROTECTED] To: fpc-devel@lists.freepascal.org Sent: Thursday, July 31, 2008 10:33 AM Subject: Re: [fpc-devel] Re: Multi threading support I think, this sounds like a misuse of interfaces. What you really need is an auto referenced class, that guarantees order and short life time. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
one thread can enter it. But I want to extend it. First, it can be applied also to classes and object: tmyclass = class(...) synchronized A class protected by a sync object is a monitor. Several other languages have this as a first class citizen. TMyClass = Monitor (xxx) This means that all classes synchronize against one critical section. For the straight case this is ok, but what about virtual methods ? Further, it allows an additional symbol to be given procedure p;synchronized mycriticialsection; it must be of the type System.TRTLCriticalSection and the procedure will be synchronized against this critical section. Besides saving the typing of endless try ... finally statements and the initialiation of the unnamed critical sections, it creates also slightly better code because the LeaveCriticalSection call can be inside the implicit exception frame which is created anyways. Any suggestions about doing it better? BTW: I'll ignore comments like nobody needs this, I need it :) For methods or classes? I think single classes with an own syncobj are the rare case? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
Mattias Gaertner wrote: On Thu, 31 Jul 2008 16:22:01 +0200 Graeme Geldenhuys [EMAIL PROTECTED] wrote: On Thu, Jul 31, 2008 at 2:59 PM, Boian Mitov [EMAIL PROTECTED] wrote: Hmm... it looks almost one to one copy from our code in Version 4.0 of our libraries ;-) . Are you one of our customers, or you have simply come with the same idea as us? I'm not Henri, but we did similar setting and auto-restoring mouse cursors in our Delphi applications. I can't imagine why I never thought of using the same idea for critical sections. :-) I think, this sounds like a misuse of interfaces. I'd say 'another use for refcounted interfaces'. Joao Morais ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
On 31 Jul 08, at 10:49, Graeme Geldenhuys wrote: On Thu, Jul 31, 2008 at 12:11 AM, Vinzent HĂśfler [EMAIL PROTECTED] wrote: a desktop system with hundreds of processors in the next few years or so. Practical benchmarks these days have shown, that a Quad-Core gains almost nothing compared to a cheaper Dual-Core in most practical circumstances. That's probably due to the currently available software all being single threaded. I remember back in the day when I used OS/2. Even though it ran on a single core system, it felt a lot more responsive that todays OS's, because most apps and the OS + WPS used multiple threads extensively. Quicker visual feedback played wonders to the illusion that it was fast. Now with todays multi-core systems it will not simply be an illusion. Well, one of the points with OS/2 is that the OS handles thread (and process) switching rather efficiently (without burning too many resources just on doing this); something not necessarily true for other operating systems including their most recent versions. Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
On 31 Jul 2008, at 14:07, Boian Mitov wrote: BTW: As it was discussed a while ago this does not work so well with Lazarus due to some optimizations they do with when a reference is decremented. No, as explained roughly ten times by now it's due to some optimisations which we do *not* do, and that assumption is wrong in Delphi as well because this particular optimisation is simply unsafe in certain cases. So please, finally, stop propagating and endlessly repeating this misinformation. See http://www.hu.freepascal.org/lists/fpc-devel/2008-June/014005.html for the full explanation. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
Jonas, Thank you! I disagree with your definition of what is optimisation, but I accept the FPC as it is. Being aware of the way it is implemented in FPC is very important to the other developers, and I was just making them aware of the danger. I am not saying you are doing it wrong (At least not any more), I am warning them that the problem exists, and they have to take some measures not get burned. I have taken such measures already, and the code seems to work with the workarounds I have implemented. I don't understand why you are reacting as if I am offending you when I am simply pointing that the specific implementation of the refference counting leads to unexpected side effects, and certain measures should be taken especially if you use the interfaces for thread locking. If there is nothing wrong with that why you are behaving so defensively? Nobody is attacking you. With best regards, Boian Mitov Mitov Software http://www.mitov.com No, as explained roughly ten times by now it's due to some optimisations which we do *not* do, and that assumption is wrong in Delphi as well because this particular optimisation is simply unsafe in certain cases. So please, finally, stop propagating and endlessly repeating this misinformation. See http://www.hu.freepascal.org/lists/fpc-devel/2008-June/014005.html for the full explanation. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
Boian Mitov schrieb: Jonas, Thank you! I disagree with your definition of what is optimisation, Well, and this is exactly the point were you are wrong (as proved by several code samples you ignored) and that's why Jonas reacted the way he did. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
In order to have peace and to make Jonas happy, please all read optimizations as unoptimizations in all my messages to this point. Please accept my apologies for using the apparently wrong term when describing the problem. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Jonas Maebe [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, July 31, 2008 2:06 PM Subject: Re: [fpc-devel] Re: Multi threading support BTW: As it was discussed a while ago this does not work so well with Lazarus due to some optimizations they do with when a reference is decremented. No, as explained roughly ten times by now it's due to some optimisations which we do *not* do, and that assumption is wrong in Delphi as well because this particular optimisation is simply unsafe in certain cases. So please, finally, stop propagating and endlessly repeating this misinformation. See http://www.hu.freepascal.org/lists/fpc-devel/2008-June/014005.html for the full explanation. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
Please peace! I will not change my opinion but I will restrain from mentioning the word optimization in this context. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Florian Klaempfl [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, July 31, 2008 2:21 PM Subject: Re: [fpc-devel] Re: Multi threading support Boian Mitov schrieb: Jonas, Thank you! I disagree with your definition of what is optimisation, Well, and this is exactly the point were you are wrong (as proved by several code samples you ignored) and that's why Jonas reacted the way he did. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
On 31 Jul 2008, at 22:14, Boian Mitov wrote: I disagree with your definition of what is optimisation Optimisation = do not use a temp, but directly assign a function result to its eventual destination. FPC's non-optimisation is that it does use intermediate temps in some cases where Delphi doesn't. I don't understand why you are reacting as if I am offending you Because we have already gone through several cycles now of a) you mentioning this alleged optimisation that FPC does which supposedly breaks interfaces behaviour compared to Delphi b) several people explaining that it is not an FPC optimisation and that it is wrong to count on it Delphi too (since it will go wrong there as well under various circumstances) c) you saying thank you for the explanation d) you again mentioning this alleged optimisation that FPC does which supposedly breaks interfaces behaviour compared to Delphi e) ... Since you're not stupid, the only other explanation I can come up with is that you are simply saying thank you to shut people up, but apart from that are completely ignoring what they actually say. And I find that indeed offensive. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
You are making a good point. I may be not that smart after all. I have been enormously frustrated by this issue, but I spent 2 weeks rewriting our code and I seem to have implemented a reasonable workaround. It has coasted me a lot, and I still feel the pain from it, so I am probably still venting unreasonably, but believe me not with bad intent, it just hurts a lot. Hopefully it is over, I am just scared of what other surprises are lurking there for me ;-) . If I have dedicated 2 weeks of work, to make sure 4 Mln lines of code are properly going to work with FPC and Lazarus, it means I am passionate enough toward the product, and I am committed to put the extra effort to support it. Passion is a double edged sword however, and comes with its dangers ;-). I am a bit too passionate I guess, and in this case it works against me and seems to hut other people, when hearting was not the intention. Please accept my apology, and understand that this is not attack against you, just display of frustration with a certain implementation that has driven me nuts for long time. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Jonas Maebe [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, July 31, 2008 2:37 PM Subject: Re: [fpc-devel] Re: Multi threading support On 31 Jul 2008, at 22:14, Boian Mitov wrote: Since you're not stupid, the only other explanation I can come up with is that you are simply saying thank you to shut people up, but apart from that are completely ignoring what they actually say. And I find that indeed offensive. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
On 31 Jul 2008, at 22:44, Boian Mitov wrote: Please accept my apology Apology accepted. And good luck with your review process! Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Multi threading support
I not only owe the haplology, but I also must say how impressed I am by the work of both FPC and Lazarus teams. I have been able to roughly port the libraries within mater of days, and some of the stuff is already working. The Interfaces issue was by far the biggest problem I have encountered, almost everything else went straight forward with minimal efforts. The teams have achieved astonishing and unbelievable quality of the project, and deserve congratulation, and gratitude for their work. I don't know if any other Delphi vendors have started supporting Lazarus yet, but I am sure we will have it supported within few months. If more vendors start supporting it, the project popularity will be ensured ( I hope :-) ). With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Jonas Maebe [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, July 31, 2008 2:48 PM Subject: Re: [fpc-devel] Re: Multi threading support On 31 Jul 2008, at 22:44, Boian Mitov wrote: Please accept my apology Apology accepted. And good luck with your review process! Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
