Hello Gerrit,
On 14.08.2010 00:19, Gerrit Voß wrote:
> On Fri, 2010-08-13 at 17:40 -0500, Carsten Neumann wrote:
>> we've run into a problem with our app that runs multiple threads on one
>> aspect when connecting it to a cluster server.
>> Consider the following scenario:
>>
>> Thread A:
>> - changes field F0 in container C
>> in FC::registerChangedContainer _pContainerChanges points to an entry in
>> the CL of Thread A.
>> - commitChanges();
>>
>> Thread B:
>> - changes field F1 in container C
>> because of the commitChanges _bvChanges == 0x00
>> so FC::registerChangedContainer runs, but only puts an uncommitted
>> change for F1 into the CL of Thread B.
>> - commitChanges();
>>
>> The change to F1 will not be transmitted over the cluster, because it is
>> lost after the commitChanges clears the uncommitedChanges list of the CL
>> of Thread B.
>
> hmm, the thing missing is how and when do you set up the change list
> for the cluster sync ??
the app never uses commitChanges directly, but instead we have a guard
object that in its d'tor commits, merges the current thread CL to a
global CL and clears the thread CL. The global CL is created on first
use and it is transmitted over the cluster.
> Which relates to how are A and B excluded from
> each other, e.g. how fine grained is the locking so that they do not
> write the same container ?
it's the apps problem to avoid that, I think we get it right. The
accesses we were having trouble with were at different points in time.
>> Attached is a patch that changes the behaviour of
>> FC::registerChangedContainer() to only skip creation of a new CL entry
>> if _pContainerChanges points into the current thread's CL.
>>
>> Comments? Other ideas to solve this?
>
> if possible I would like to avoid the round trip through the thread.
it has always gone through the thread to add the uncommitted entry at
the end, so there should be no *new* TLS access with the patch.
Cheers,
Carsten
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
