Menu
▾
▴
corelinux-develop
|
From: Frank V. C. <fr...@co...> - 2001-09-09 10:26:20
|
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 For each one of these there is a lengthy discussion and I've yet to discuss the implications to the FrameworkEntity types. Lets talk this one out as it is near and dear to my heart :). I have a tremendous experience with SP in large complex application work, and I don't want to take this lightly. Frank V. Castellucci "Watch the donut, not the hole" |
|
From: Ian C. <co...@st...> - 2001-09-09 16:19:42
|
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. -- ----------------------------- http://www.stasis.org/~codic/ |
|
From: Frank V. C. <fr...@co...> - 2001-09-09 18:30:03
|
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. > |
|
From: Ian C. <co...@st...> - 2001-09-11 02:42:21
|
On Sun, 9 Sep 2001, Frank V. Castellucci wrote: > 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. Um... I don't follow. I'm sure it's just my inexperience shining through. Each SP obviously needs a (dumb) pointer and a reference count. Modifications to these need to be thread safe, right? Now... it would be pure evil to give each SP type a static locking mechanism. I've done it by giving each SP instance a mutex, but is this overkill? You mention semaphores... are you talking about implementing mutexes/critical sections (for pointer/ref. count mods) with semaphores? If not, I'm lost. As for semaphore pools... are you talking about something clever to avoid my (wasteful?) "mutex for each instance" scheme? Like I said, I don't follow. :( > 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? Does this replace #7 or is it over and above it? If the latter, then what does #7 really mean? [for reference...] > >>7. Must be re-entrent -- ----------------------------- http://www.stasis.org/~codic/ |
|
From: Frank V. C. <fr...@co...> - 2001-09-11 10:08:09
|
Ian Crawford wrote: >On Sun, 9 Sep 2001, Frank V. Castellucci wrote: > >>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. >> > >Um... I don't follow. I'm sure it's just my inexperience shining >through. > >Each SP obviously needs a (dumb) pointer and a reference count. >Modifications to these need to be thread safe, right? Now... it would be >pure evil to give each SP type a static locking mechanism. I've done it >by giving each SP instance a mutex, but is this overkill? > It is overkill, but I believe you get the idea of the semaphore (mutex) pool now. > >You mention semaphores... are you talking about implementing >mutexes/critical sections (for pointer/ref. count mods) with semaphores? >If not, I'm lost. > You are not lost, and I apologize if my phrasing isn't clear, your doing fine. > >As for semaphore pools... are you talking about something clever to avoid >my (wasteful?) "mutex for each instance" scheme? Like I said, I don't >follow. :( > You follow, this is a clever way, but has a price. > > >>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? >> > >Does this replace #7 or is it over and above it? If the latter, then what >does #7 really mean? > Again, re-entrancy and guarded (mutex) are two different things neh? > > >[for reference...] > >>>>7. Must be re-entrent >>>> > |
|
From: Ian C. <co...@st...> - 2001-09-11 12:58:07
|
On Tue, 11 Sep 2001, Frank V. Castellucci wrote: <snip> > >As for semaphore pools... are you talking about something clever to avoid > >my (wasteful?) "mutex for each instance" scheme? Like I said, I don't > >follow. :( > > > You follow, this is a clever way, but has a price. I figured it would. :) > >Does this replace #7 or is it over and above it? If the latter, then what > >does #7 really mean? > > > Again, re-entrancy and guarded (mutex) are two different things neh? Alright. To make sure we're on the same page: I presume you mean that all R/O operations involving the underlying pointer be re-entrant. And the write operations must be guarded. Yes? Ian. -- ----------------------------- http://www.stasis.org/~codic/ |
