Active Oberon also adds concurrency into the language, a feature that I really want FPC to have someday, while having a closer to Object Pascal syntax for object definition (which is a class in OP).
The main problem with concurrency in all programming languages / models I know, is the use of threads with shared memory.
If you have two threads, that both access the same variable, you are encouraged to use a mutex to lock and unlock that variable. This is how it is done.
And that's totally the wrong way to do it.
Every time you lock the variable, you serialize the application. And not only that, but it incurs a large overhead and makes context switching take ten times as long:
- The shadow registers need to be cleared.
- The pipeline needs to be flushed.
- The cache memory needs to be partially flushed.
- the page tables need to be refreshed.
In the time that takes, the CPU could have done more work than a 8086 could do in a whole second.
Ergo, working like that makes your application slower instead of faster.
That's why the amount of CPU cores on Intel x86 processors first climbed up to 16, and is now back down to max four. Simply because few people have figured out how to use them effectively.
Essentially, you need to give each thread its own (thread-safe) message queue, which triggers execution on post. And use that for both events as well as data passing. That increases the latency, but the throughput as well.
There should be no shared memory. If you want to pass a block of data, allocate it on the heap, post the pointer and nil your own copy of the pointer.