Re: [Opensg-core] CL Entry cache in FC and multiple threads on one aspect

[Carsten N. <car...@gm...>]

	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