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: 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: 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: 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
