4D v16 R6 introduces a new concept of communication between processes: shared object and shared collection variables! They are a solution so you can avoid using interprocess variables (which can’t be used in multi-thread mode). Thanks to this, you will be able to easily share information between preemptive processes.
New concept: shared objects / collections
In the computer programming world, when you need performance, the less you share data, the most efficient you are. But of course, in most of case the processes you have created must communicate together. Either to send parameters, to get results or simply to access some shared information. That’s the reason why shared objects and shared collections have been created! (Just remind that regular objects and collections cannot be shared between processes. When they are passed as parameters, a copy of the objects are created.)
Shared objects and shared collections behave just like standard ones, except they must be declared as “shared” during their instantiation with the following new commands: New shared object and New shared collection. Once instantiated, they can be used directly, just like any other ones, for reading. No semaphore or anything else is needed, just use the shared objects.
For writing or modifying, the shared objects must be surrounded by the Use and End use keywords. These keywords set internal semaphores, and must be employed to access the content of objects and collections in Write mode. The use of these keywords is really easy, much easier than the 4D language semaphores. How so? You can’t forget to free them. Use and End use always surround the variables, so you can’t forget to release the lock.
$object:=New shared object
$ps:=New process("my process";0;"myprocess";$object) // sent as reference
Use ($object)
$object.myAttribute:=10
End use
How to use them in other processes?
You may be wondering: How can I use a shared object from another process (in other way than sending a parameter)? How can I share without interprocess variables?
A “super-shared” object solves this. A new command, Storage, provides access to this object, for all running processes.
This object is unique on each machine. One (in Single User mode), otherwise one per client and one on the server. The Storage command returns the shared object so it can be manipulated like any other shared object, but it can only contain shared objects or shared collections. (Note that components can hold Storage their own as well)
Use (Storage)
Storage.myCollection:=New shared collection
End use
Benefits
Shared objects and shared collections have many advantages compared to standard interprocess variables, such as:
- no need for protection when reading: fast access
- Use and End Use keywords avoid coding errors resulting in deadlock scenarios
- because objects or collections are usually hierarchical (containing other objects or collections), by locking an object you lock the whole chain at once, improving performance.
You will quickly get used to shared objects and collection and it’s going to become a natural way of programming 🙂