Possible to lose modifications through concurrent operations
If multiple Smalltalk Processes concurrently manipulate the same replicate,
it is possible for a change to that replicate to be lost. For this to happen,
specific circumstances must be occur in a quite narrow time window.
Specific circumstances:
In most versions of GBS, if one Process modifies a replicate while another
process is making the replicate into a stub, the modification can be lost.
Replicates become stubs due to either an explicit request or as the result
of server execution if the object has changed on the server and its fault
policy is #lazy.
In a few versions of GBS, if one Process modifies a replicate while another
Process is initiating server execution, the modification can be lost.
When using the GBS automatic dirty-marking feature in VA Smalltalk and
VisualWorks 7.x, it is possible for GBS to make these failures impossible.
In VisualWorks 5i, making automatic dirty-marking immune to these failures
would slow execution down, so we do not anticipate ever fixing this problem
in VisualWorks 5i.
All applications which manually mark objects dirty are vulnerable to this
problem.
We recommend that all customers use VisualWorks 7.x or VA Smalltalk, and
that that their applications use automatic dirty-marking. If you must use
VisualWorks 5i or manual dirty-marking, the application must be very careful
when accessing sessions and their replicates from more than one Smalltalk
Process.
Workaround
No workaround
Last updated: 7/18/11