Is there anything like Java Memory Model in Delphi? To prevent misunderstandings: I mean nothing like "huge/large/small", but the things related to visibility of changes to other threads.
Delphi Pascal includes features to support concurrent programming—not as much support as you find in languages such as Ada, but more than in most traditional programming languages. In addition to the language features, you can use the Windows API and its semaphores, threads, processes, pipes, shared memory, and so on.
Using a future is as simple as accessing a property. All the synchronization is handled automatically by TFuture. Concurrent programming can be tricky, but with care and caution, you can write applications that use threads and processes correctly, efficiently, and effectively. Get Delphi in a Nutshell now with O’Reilly online learning.
The original Java memory model, developed in 1995, was widely perceived as broken, preventing many runtime optimizations and not providing strong enough guarantees for code safety. It was updated through the Java Community Process, as Java Specification Request 133 (JSR-133), which took effect in 2004, for Tiger (Java 5.0).
The easiest way to create a multithreaded application in Delphi is to write a thread class that inherits from TThread . The TThread class is not part of the Delphi language, but is declared in the Classes unit. This section describes the class because it is so important in Delphi programming.
I'd say the Delphi memory model matches the C++ memory model. That is, the compiler is not aware of multiple processes or multiple threads and does not provide any special support for those scenarios. See "What is the C++ memory model for concurrency?"
The Delphi 32 bit compiler does perform optimizations such as invariant code motion and does emit instruction sequences designed to avoid stalling dual pipelines. However, the Delphi compiler does not contain an instruction scheduler or peephole optimizer, so opportunities for instruction reordering are slim to none. Delphi optimizations occur on the AST / IR before instruction emit.
Local variables may be enregistered, but any source code reference to a variable that requires a memory address (such as passing a local variable to a var param, or taking the address of a local var) will force the compiler to commit the enregistered value to a memory location prior to use of the address, or may force the compiler to completely abandon enregistering the variable at all.
The Delphi 32 bit compiler is fairly conservative in its optimizations. The biggest performance gains from optimizations are from enregistering variables and intermediate results, and from various loop induction tricks.
Operations on global symbols or symbols residing in global memory (such as object fields) are not enregistered. There is no "volatile" modifier.
The compiler codegen patterns rely on the x86 architecture rules that register-sized writes to global memory at aligned addresses are atomic. Writing of large data, byte data, or at unaligned addresses may cross a cache line and require two separate write operations within the single write instruction. The Delphi compiler is (mostly) oblivious to this.
Regardless, if you are writing Delphi code that accesses shared memory from different threads, it is always your responsibility to decide what thread synchronization measures are appropriate to your situation and implement them.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With