[closer-devel] Thread-safety in ContextL, and related news

[Pascal Costanza]

Ah, I forgot to mention: The locks are only acquired on the slow  
paths, not on the fast paths. So as soon as the caches are filled,  
locks will never be acquired again. Therefore, the overall performance  
of ContextL shouldn't suffer from this change.

I just thought this may be interesting to some...

Pascal

On 12 Nov 2007, at 18:06, Pascal Costanza wrote:

> Hi,
>
> I have now added the necessary synchronization to (hopefully) ensure  
> that layer context caches are thread-safe in ContextL. I also  
> checked the rest of the ContextL, and found one other place where  
> synchronization is necessary, and added the necessary code as well.  
> (The changes are only in the repository, not in the official version  
> of ContextL yet.)
>
> The synchronization is done in a way that the caches won't hold  
> duplicate entries, and creating a cache entry should always lead to  
> a proper update of the cache - so cache entries cannot be missed by  
> other threads. It should even be the case that CL implementations  
> with 'real' parallelism on multicore architectures should also be  
> safe (whether this matters at the moment or not is a different  
> question ;).
>
> ContextL now depends on portable-threads of the GBBopen project.  
> Please go to http://gbbopen.org/ and download the whole package from  
> there - I have tested against the version in their SVN repository.  
> You need to add gbbopen.asd to your asdf central registry, GBBopen  
> figures out the rest for you. (There is also an asdf-install version  
> of portable-threads, but that one seems to be outdated. GBBopen  
> doesn't seem to be asdf-installable itself, but I am not sure - I  
> actually don't use asdf-install myself.)
>
> I have run my test suites successfully on Allegro 7.0, 8.0 and 8.1;  
> clisp 2.42 (aka 2.41.1), CMUCL 19d, LispWorks 5.02, OpenMCL 1.0 and  
> SBCL 1.0.11. I couldn't test MCL, because GBBopen doesn't compile  
> for MCL - I will report this to the GBBopen guys. LispWorks 4.4.x  
> doesn't run on Leopard anymore, so I cannot test it. (I will  
> probably remove support for LispWorks < 5.0.x in the next release of  
> ContextL.)
>
> Please let me know if there are any problems or questions.
>
>
> Best,
> 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
>
>
>
>
> _______________________________________________
> closer-devel mailing list
> closer-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/closer-devel

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