On Fri, 26 Sep 2008, Przemyslaw Czerpak wrote:
> Publics are really global and the assign is done in atomic
> operation what is the additional necessary protection I was writing
> about in previous message. But to make it fully safe also access has
> to be done as atomic operation or they have to extensively use GC.
But I'm looking at the code example and for me it's not MT safe or
xBase++ makes sth else what is not documented.
> I ussually carry aplication-wide info in a public array protected by a public
> logical var
>
> EJ:
>
> public aConfig := {.t.}
> public lInUse := .f.
>
> then in each thread when I want to modify the array I do (simplified example,
> it is usually encapsulated in a class):
>
> do while lInUse
> enddo
> lInUse := ! lInUse
> if lInUse // another thread may come in the interim
> aadd(aConfig,'elem')
> lInUse := ! lInUse
> endif
In this code we have:
lInUse := ! lInUse
To make this code MT safe the above line has to be one atomic
operation in xBase++. Is it true?
If not then two threads can at the same time read lInUse receive
.f. then each of them will revert its value and store in atomic
operation into lInUse.
Then both will pass successfully the test:
if lInUse // another thread may come in the interim
and will make aadd().
On single CPU machine and seldom calls two above code it may
work 99.9% of cases and will fail only when OS change active
thread context between access and assign operations in line:
lInUse := ! lInUse
But in multi CPU ones when cost of operation inside
if InUse
...
lInUse := ! lInUse
endif
is relatively high then you have big chance that two threads will
be blocked simultaneously at:
do while lInUse
enddo
then both will be unblocked and you have very big chance that they
will make next instruction well synchronized and both will access
the critical section.
The key is in:
lInUse := ! lInUse
line. This code can be MT safe _only_ if xBase++ executes this
whole line as one atomic operation.
So far I haven't found any information about such functionality.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
