Re: [Sbcl-devel] wip: DEFGLOBAL

[Daniel H. <dhe...@te...>]

On Sun, 26 Apr 2009, Nikodemus Siivola wrote:

> 2009/4/26 Faré <fa...@gm...>:
>
>> Following this line of reasoning, even DEFVAR would be bad
>> unless DEFVAR itself is atomic between the moment it checks for boundp
>> and the moment it commits the new value.
>
> Um. I find that a fairly extreme position. I think it's reasonable to
> assume that you may during development be reloading code that happens
> to have things like
>
> (defvar *lock* (make-mutex))
>
> in it while threads holding those locks are running, in which case
> DEFVAR does TRT -- keeps the old lock in place instead of nuking it.

I think Fare's point still holds for actions which have costly side 
effects.  People might think it is safe to use defvar to initialize shared 
resources as part of thread initialization.

e.g.
(defvar *space* (allocate-1GB-or-die))
(defvar *port* (open-serial-port-or-die))

That said, the standard procedure in other languages is to initialize such 
shared structures before spawning new threads (or telling existing threads 
to use them) or use explicit synchronization (e.g. a mutex or 
pthread_once) to coordinate their initialization at runtime.  So I see no 
need to use a mutex or atomic op in DEFGLOBAL just as long as the 
documentation is clear.

Since (IIRC) special variables are stored thread-local, this looks like a 
good way to define global (static, shared) storage.

- Daniel