>> >? Isn't that what's being done (same code as I suggtested in #1496291)
>
>Yes - I was just wondering
>Suppose the first line says it's been initialized and just after that line the value of oApp.lInitialize changes ?

>I would not use the first line - and always test the value of oApp.lInitialize inside a SyncLock section ?, iow only access oApp.lInitialize from within a SyncLock
>
>Paranoia ?

I guess the assumption is that there is no code that will set oApp.lInitialize false........
OTOH, the only downside to removing the outer IF is that the time consuming lock will be executed whether it is neccessary or not?


>The code of #1496291
>
>

>If Not oApp.lInitialize Then
>>>        SyncLock locker
>>>            'Check again inside safe section
>>>            If Not oApp.lInitialize Then
>>>                'Do stuff
>>>                oApp.lInitialize = True
>>>            End If
>>>        End SyncLock
>>>  End If
>>>'Where locker is:
>>>Private Shared locker As New [Object]()
>

>
>
>>? Isn't that what's being done (same code as I suggtested in #1496291)
>>
>>>Wouldn't it be safer to first use SyncLock and then test oApp.lInitialize ? If not, I see a possible race condition
>>>
>>>

>>>            SyncLock oApp.oObjectLock
>>>                  If Not oApp.lInitialize Then
>>>                        If Not LoadDataDictionary() Then
>>>                            Return False
>>>                        End If
>>>

>>>
>>>
>>>>You're welcome! =0)
>>>>
>>>>~~Bonnie
>>>>
>>>>
>>>>
>>>>>>Yes, that *is* what I meant by the double-check locking pattern (by checking first, you only get the lock if you need to) .... however, it seems to me that if you implement this pattern, then there's no reason that you even need to check both oApp.lFirstHit and oApp.lInitialize, is there? I mean, you're initializing only on the FirstHit anyway, so I would think you could simplify this to just the following:
>>>>>>
>>>>>>

>>>>>>            If Not oApp.lInitialize Then
>>>>>>                SyncLock oApp.oObjectLock
>>>>>>                    If Not oApp.lInitialize Then
>>>>>>                        If Not LoadDataDictionary() Then
>>>>>>                            Return False
>>>>>>                        End If
>>>>>>

>>>>>>
>>>>>>And then you could totally remove the lFirstHit property from oApp (unless you're using it for something else also).
>>>>>
>>>>>I had to do some testing to see if that was the equivalent use and yes. So, I got rid of that property. Your schema is the one I have right now. I do have additional similar processes when the data dictionary changes along the route, but at first, it is exactly like that. I am doing some more testing tonight but it sounds good.
>>>>>
>>>>>Thanks