[fpc-devel] Re: Multi threading support

[Florian Klaempfl]

Vinzent Höfler schrieb:
> -------- Original-Nachricht --------
>> Von: Florian Klaempfl <florian at freepascal.org>
>> 
>> 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.
> 
> You mean:
> 
> 1) All classes of the type (and descendants)?

Yes. This was my idea so for.

> 2) Only the methods additionally marked with a "synchronized"
> statement?

No.
> 
> 3) Corollary: A critical section is either class wide or instance
> wide? Meaning: you can't possibly use both approaches at the same
> time? For instance, having some methods that are synchronized between
> all instances existing (class wide) _and_ another set of methods only
> synchronized on the instance? If so, maybe the syntax below could be
> extended to specify how the synchronization should be done without
> the explicit use of another RTLCriticalSection? (Maybe "synchronized
> class" for the class-wide one, a simple "synchronized" for the
> instance-wide?)

Yes, this is something to think about.
- class wide
- instance wide
- method/procedure wide
One overrides the other, i.e. if there is a class wide synchronized, the 
compiler will throw an error if there is a method one.

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

>> Any suggestions about doing it better?
> 
> Warnings, if you use potentially blocking functions inside a
> synchronized method? ;)
> 
> Like:
> 
> |procedure My_Thread.Do_Work; synchronized; |begin |   ... |
> Suspend; |end;
> 
> Well, I guess the compiler doesn't know which operations are
> potentially blocking, does it?

No.