[Openmcl-devel] 3 questions - TLS the default? global thread-shared vars? .CDB gen broken?

[Gary Byers]

On Sat, 19 Mar 2011, Jason E. Aten wrote:

> Hi, ?I now have a project that I love to use CCL on, but I'm just learning
> my way around this system.
> 
> I have generated three questions as I'm getting started with CCL. ?The
> context is: I'm running on ubuntu 10.04 x86_64, with CCL 1.6 / LinuxX8664.
> 
> 1) I have to allocate alot of thread-local variables (so that they won't
> require locking), and a substantial number of shared-between-thread
> variables that will require a mutex. In looking through the documentation
> for CCL, I get the impression that by default all variables are thread
> local. ?If someone could confirm for certain this impression, that would be
> great.

First of all: if you aren't already familiar with the issues and terms,
you want to make sure that you understand the differences between lexical
and special variables in Common Lisp.  If you're at all unsure about that
understanding, you might find Ron Garrett's "The Idiot's Guide to Special
Variables and Lexical Closures" (<http://www.flownet.com/gat/specials.pdf>)
useful.  As its title implies, that paper also contains an interesting
discussion of lexical bindings and lexical closures; your question seemed
to be about special variables and special bindings, so we'll concentrate
on those issues and (mostly) try to use the same terminology as Ron (Erann)
did.

To extend that terminology very slightly, it's helpful to distinguish between
"static" and "dynamic" bindings of special variables.  When constructs like LET,
LET*, LAMBDA ... establish bindings of special variables, those bindings 
are dynamic: they're in effect until the binding construct exits and can be
shadowed by dynamically more recent bindings of the same variable.  All special
variables also have static bindings, which are in effect when not within
the extent of a dynamic binding construct.

Dynamic bindings are thread-local; static bindings are not. The visible/effective
binding of a special variable in a particular thread is:

- the most recently established dynamic binding in that thread, if any
- the global, shared, static binding otherwise.

David Rager's response showed how establishing a dynamic binding of a special
variable in a thread made that binding thread-local.

In general, all special variables can have dynamic bindings (but see below)
and can therefore be considered thread-local.  Whether a variable has a
thread-local visible value or not in a given thread depends entirely on
whether or not a dynamic binding of that variable is in effect in that
thread at a particular point in time.

?
> 
> 2) How does one allocate or a thread-shared variable (of infinite extent,
> i.e. from the heap, not on the stack), in contrast to a
> thread-locally-stored varaible? In order words, when two different threads
> need to be able to name the same variable (after locking the thread inspects
> the shared variable, possibly updates it, then releases the lock), how do I
> tell lisp this is what I'd like?

One answer is "ensure that no thread ever establishes a dynamic binding
of the variable."  Some combination of Good Clean Living and careful
discipline can sometimes enforce this constraint (or so I'm told ...)

Raffael Cavallaro mentioned DEFSTATIC, which tries to enforce this constraint
for you (and also documents that it's in effect.)


> 
> 3) I was able to build the ffigen without issue, however
> CCL::PARSE-STANDARD-FFI-FILES doesn't seem to work, ?producing "Error: The
> directory #P"ccl:x86-headers64;subdir;" does not exist, cannot open/create
> #P"ccl:x86-headers64;subdir;new-constants.cdb.newest"
> 
> As an aside, I note that the documentation on how to produce .cdb files
> seems to have some odd symbols in it, reminiscent of a corrupt/incomplete
> latex compilation. ?Specifically,??"ccl:headers;subdir;C;populate.sh" is
> shown in certain places in the docs, and appears also to be used somehow in
> the source code, but represents a non-usable path on Linux, which seems to
> be causing the issue (perhaps?) Specifically, I'm following these
> instructions. Please advise if there are others? :

If you're not familiar with logical pathnames in CL, it'd probably be a good
idea to learn about them.  The pathname above is a logical pathname; the
directory names "headers" and "subdir" are intended as metavariables.
You seem (in a later response) to have discovered the latter part of that;
I don't remember what typographical conventions are used to indicate that,
but without them this sort of thing can degenerate into a bad Abbot and
Costello routine ("You pass the path containing SUBDIR to the program."
"I did, and it said that SUBDIR didn't exist.")