[closer-devel] *root-context* and threads

[Pascal Costanza]

On 6 Nov 2007, at 15:53, Attila Lendvai wrote:

>> These options are easier and have less undesirable implications than
>> changing the code to protect it against concurrency issues, and they
>> may help to localize your problems.
>>
>> Let me know what you think would work best for you at the moment...
>
> just take your time to find the proper strategy in contextl. the
> machines can mostly keep up with the load and this is not a mission
> critical app, so if one or two restarts happen it's bearable...

OK, that's good to know.

I am also already getting some good answers, so I think I will be able  
to solve the ContextL cache issues...

> and i think the issue is localized in sbcl (Nikodemus listed what the
> things are that need to be protected from concurrent access).
>
>>> but having a protected global cache for the created classes/ 
>>> prototypes
>>> may be a good idea nevertheless, because it would probably speed
>>> things up in a threaded environment.
>>
>> I doubt that. A cache is faster when it's small, and keeping the
>> caches for layer children local to their parents keeps them small -
>> and a small cache justifies the use of a property list, which should
>> even make it faster. So I'd like to stick to that, if possible.
>
> i have no numbers, but you should also consider that calling
> make-instance on classes, then dispatching on their instances has many
> "invisible" performance penalties. huge locks must be held while
> defining the class, method caches must be flushed and refilled for new
> instances, etc...

I strongly believe that I have taken taken all these issues into  
account, and that the current approach is optimal. A global cache  
would probably make things worse, as far as I can tell.

For example, I think I have reduced the creation of new instances to a  
minimum, and method caches should never be flushed in the current  
ContextL implementation. I have been hit seriously by method cache  
flushes for 'special' functions in AspectL, so I invested some time  
into redesigning what has now become layered functions in ContextL.

But I'd be happy to be proven wrong, so I can improve things, if  
possible...

>> Unless you have performance issues, which I'd like to know about, of
>> course. I haven't been able to test ContextL with a large-scale
>> application yet...
>
> i'll report back if i have any numbers/thoughts, but for now
> performance is not a critical issue.


OK, good.


Pascal

-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium