Just a few more comments:


> >
> >The problem is that any key in a WKDict can be garbage collected and
> >set to nil, by the gc thread. Naturally, this can break just about any
> code
> >accessing the WKDict.
> 
> I'm not sure what needs to break. Checking for <nil> should avoid such
> problems (see example further down).
> 
> 
>   I probably should have put some more context to the problem. There is in
> effect a two dimensional
>  array of WKDicts. The first has the publishers as its keys. Each of its
> values holds a WKDict holding
>  as its keys all the subscribers for that particular publisher. The
> subscriber dict links to further structs like
>   events keys, and messages to send. You get the idea....   So I can test
> the publishers
>   dict by - publishers at: thisObject. Then follows a bunch of methods,
> each
> digging deeper into
>   the data structure, and finally sending a message to the intended
> receiver. While these messages
>  are executing the publisher or the subscriber key can dissapear from its
> dictionary.
>   The problem may also be that in my threading tests, the WKDicts are
> getting an incoming stream of new  Objects with no strong references, so
> the
> arrays are continually being resized. Perhaps the problems
>   are due to array resizing during concurrent access.
> 
I'd say the problem is just general synchronization. Since you depend on the
WKDicts not to be changed during this series of operations you have to make
sure that no concurrent process can work on it while you're doing your
operation. This is exactly what the WeakRegistry does. It wraps every access
to the actual data into the message 'WeakRegistry>>protected: aBlock' using
a semaphore to serialize the access (and this is what I meant in my previous
email by checking out WKRegistry). The only difference in your scheme is
that you would have to serialize the access twice (since you've got a
two-dimensional structure).

> >So in essence, one must guarantee that any WKDict instance will not
> >receive any messages immediately after Finalization Semaphore signals,
> >and it's finalizeValues method is invoked. It seems to me that any
> >message that is part of a process with higher priority than the
> >finalizationProcess
> >in class WeakArray will break this guarantee. Random synchronization
> >problems will occur.
> 
No. Not if you use Semaphore>>critical:. This will stop any higher priority
process if the guarded region has already been entered by *any* process
regardless of it's priority.

  Andreas
--
+===== Andreas Raab ========= (andreasr at wdi.disney.com) ==+
| Walt Disney Imagineering        Phone: +1 818 544 5016  I
I Glendale, CA                    Fax:   +1 818 544 4544  I
+======< http://isgwww.cs.uni-magdeburg.de/~raab >========+