bitRake,
As far as I understand, the author of the first post wants
restickt access to some shared value during some PART
of code not just for one READ FROM MEMORY instruction,
in other words: in your code is part you called
...do something...
so I thought he didn't want the value to be access\changed
the whole "...do something..." part.
Am I wrong?
'Cause if I'm right I don't see how you prevent it to hapenned
if thread switches in a middle of "...do something.."
Posted on 2002-11-07 17:18:38 by The Svin
Svin, imagine an array of dwords:

pObject1
pObject2
pObject3
...

A thread executes, getting exclusive use of an availible object pointer - replacing that pointer with zero:

00000000
pObject2
pObject3
...

Another thread executes, skips first dword getting second free pointer. No other thread can use the pObject1 until the first thread puts it back. This is a very flexible set-up as the pointer doesn't even have to be the same. The pointer isn't even there for other threads to use, and if they tried to use the zero the error would quickly surface.

It is like putting a clear box wherever you take a book off the shelf - you know the book is gone, but you don't know what book it is and certainly can't use it until it is returned.

I will explain more if needed...
Posted on 2002-11-07 17:41:05 by bitRAKE
I think it depends a lot on the application. In my app, I allocate say a meg which I split into 4 kb buffers. I don't need to store pointers, cause it's easy enough to calculate the buffer ptr from the index and the memory base.

However, for generic objects "somewhere" in memory you're going to have store pointers regardless, in which case bitRAKE's method wouldn't use and "extra" memory...


Ciao for now

--Chorus
Posted on 2002-11-07 19:02:58 by chorus

Svin, imagine an array of dwords:

pObject1
pObject2
pObject3
...

A thread executes, getting exclusive use of an availible object pointer - replacing that pointer with zero:

00000000
pObject2
pObject3
...

Another thread executes, skips first dword getting second free pointer. No other thread can use the pObject1 until the first thread puts it back. This is a very flexible set-up as the pointer doesn't even have to be the same. The pointer isn't even there for other threads to use, and if they tried to use the zero the error would quickly surface.

It is like putting a clear box wherever you take a book off the shelf - you know the book is gone, but you don't know what book it is and certainly can't use it until it is returned.

I will explain more if needed...

It's a very creaative idea,Rickey,
but what is pObject,
if it is variable then what if zero might be one values,
I mean meaningfull values?

It reminds me of ColorDialog from m32lib,
Steve decided to use (to return) 0 to indicate that user pressed
cancel on ChooseColor dialog, but at the same time
when user didn't press cancel and select Black it also
returns 0 - value of Black, and it is impossible to differ if zero is returned - wether user pressed cancel or just chosed black.
The with the case: it works only if there are not supposed to be 0 values in those vars in memory.
Using pObj as pointers to the vars will lead to use additional memory and all saving memory advantage is gone.
What else I don't understand?
Posted on 2002-11-07 20:16:03 by The Svin
Svin, you are correct - if memory pointers are not needed then another method might be a better choice. I am unaware of what the case is for goto - I assumed he had pointers in the 'Table'. If it is an array of structures maybe this method can still be used - as you point out, zero would have to be an invalid response to whatever is XCHG'd. As chorus points out: this is application specific.
Posted on 2002-11-07 20:38:53 by bitRAKE
Anyway I like logic of your algo, and filed its abstruct scim.
Posted on 2002-11-08 15:01:51 by The Svin