Re: [Corelinux-develop] Smart Pointers

[Frank V. C. <fr...@co...>]

To answer your first question:

It is all to often we see the myopic view of the world where context 
often become part of a static type. For example, rather than take the 
time to create things like semaphore pools, a developer unilateraly 
decided that each SP type (A, B, Foo, etc.) has a single semaphore in a 
static variable. ugh.

And now that you brought it up (if you knew it or not with reference count):

8. Reference counts must be guarded
9. Object state must be guarded

Thoughts?

Ian Crawford wrote:

>On Sun, 9 Sep 2001, Frank V. Castellucci wrote:
>
>>Smart Pointers (in no order):
>>
>>1. Should be able to be garbage collected
>>2. Should be able to release the object that it points to when asked
>>3. If needed (dirty object), the object being released should be
>>persisted (paged out)
>>4. If requested again, with the object paged out, it should be paged in
>>5. Must have a reference counter, not just a single "in use" notion
>>6. Must be created and destroyed by a factory (this make caches and
>>memory management much easier)
>>7. Must be re-entrent
>>
>
>Just to clear up some terminology, when I think "re-entrent", I envision a
>function that, using a context pointer or some other device, can be called
>by more than one thread simultaneously with out further use of
>synchronization objects like mutexes.  Something that requires extra
>synchronization logic I just think of as being "thread-safe".  Is there
>really a difference, or is it just me?
>
>Anyway, I wouldn't ask if I wasn't curious how you planned to make things
>like reference counting re-entrent.  Maybe it's just my definitions that
>are screwy, or maybe you have some truly magical ideas. Or both! :)
>
>Ian.
>