Vinzent Höfler schrieb:
-------- Original-Nachricht --------
Von: Florian Klaempfl <[EMAIL PROTECTED]>
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.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
