clisp-cvs Digest, Vol 43, Issue 5

[clisp-cvs-request]

Send clisp-cvs mailing list submissions to
        clisp-cvs@...

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.sourceforge.net/lists/listinfo/clisp-cvs
or, via email, send a message with subject or body 'help' to
        clisp-cvs-request@...

You can reach the person managing the list at
        clisp-cvs-owner@...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of clisp-cvs digest..."


CLISP CVS commits for today

Today's Topics:

   1. clisp/src ChangeLog,1.7190,1.7191 eval.d,1.275,1.276
      (Sam Steingold)
   2. clisp/doc impext.xml,1.629,1.630 (Sam Steingold)
   3. clisp/src ChangeLog,1.7191,1.7192 zthread.d,1.72,1.73
      (Vladimir Tzankov)


----------------------------------------------------------------------

Message: 1
Date: Wed, 04 Nov 2009 16:33:21 +0000
From: Sam Steingold <sds@...>
Subject: clisp/src ChangeLog,1.7190,1.7191 eval.d,1.275,1.276
To: clisp-cvs@...
Message-ID: <E1N5inR-0004Z1-Sf@...>

Update of /cvsroot/clisp/clisp/src
In directory ddv4jf1.ch3.sourceforge.com:/tmp/cvs-serv17521/src

Modified Files:
        ChangeLog eval.d
Log Message:
(interpret_bytecode_): fix a type error in the last patch


Index: eval.d
===================================================================
RCS file: /cvsroot/clisp/clisp/src/eval.d,v
retrieving revision 1.275
retrieving revision 1.276
diff -u -d -r1.275 -r1.276
--- eval.d 3 Nov 2009 21:10:31 -0000 1.275
+++ eval.d 4 Nov 2009 16:33:18 -0000 1.276
@@ -6429,11 +6429,11 @@
       var uintL n;
       U_operand(n);
     #if defined(MULTITHREAD)
-      var Symbol sym=TheSymbol(TheCclosure(closure)->clos_consts[n]);
-      if (sym->tls_index == SYMBOL_TLS_INDEX_NONE) {
+      var object symbol = TheCclosure(closure)->clos_consts[n];
+      if (TheSymbol(symbol)->tls_index == SYMBOL_TLS_INDEX_NONE) {
         var uintC mvc = mv_count;
         mv_to_STACK(); /* save mv_space */
-        with_saved_context({add_per_thread_special_var(sym); /* maygc */});
+        with_saved_context({add_per_thread_special_var(symbol); /* maygc */});
         STACK_to_mv(mvc); /* restore mv_space */
       }
     #endif

Index: ChangeLog
===================================================================
RCS file: /cvsroot/clisp/clisp/src/ChangeLog,v
retrieving revision 1.7190
retrieving revision 1.7191
diff -u -d -r1.7190 -r1.7191
--- ChangeLog 3 Nov 2009 21:10:31 -0000 1.7190
+++ ChangeLog 4 Nov 2009 16:33:16 -0000 1.7191
@@ -1,3 +1,7 @@
[phone]  Sam Steingold  <sds@...>
+
+ * eval.d (interpret_bytecode_): fix a type error in the last patch
+
 2009-11-03  Vladimir Tzankov  <vtzankov@...>
 
  [MULTITHREAD]: create dynamic bindings for all special variables




------------------------------

Message: 2
Date: Wed, 04 Nov 2009 16:44:48 +0000
From: Sam Steingold <sds@...>
Subject: clisp/doc impext.xml,1.629,1.630
To: clisp-cvs@...
Message-ID: <E1N5iyW-00053b-BS@...>

Update of /cvsroot/clisp/clisp/doc
In directory ddv4jf1.ch3.sourceforge.com:/tmp/cvs-serv19423

Modified Files:
        impext.xml
Log Message:
add mt-random


Index: impext.xml
===================================================================
RCS file: /cvsroot/clisp/clisp/doc/impext.xml,v
retrieving revision 1.629
retrieving revision 1.630
diff -u -d -r1.629 -r1.630
--- impext.xml 2 Nov 2009 22:47:35 -0000 1.629
+++ impext.xml 4 Nov 2009 16:44:45 -0000 1.630
@@ -4790,6 +4790,14 @@
    visibly modified with regard to the equivalence test of H, then the
    consequences are unspecified if O1 is used as a key in further
    operations on H...</para></blockquote></para>
+
+<section id="mt-random"><title>&random; and &random-state-t;</title>
+<para>&random; modifies a &random-state-t; &without; locking, which
+means that you &cannot-e; carelessly share such objects between threads.
+However, &random-state-var; is bound per-thread (see &make-thread; and
+&default-special-bindings;), i.e., each thread has its own value and
+thus &random; &is-e; thread-safe.</para></section>
+
 </section>
 
 <section id="mt-unsafe"><title>Examples of thread-unsafe code</title>




------------------------------

Message: 3
Date: Wed, 04 Nov 2009 22:10:17 +0000
From: Vladimir Tzankov <vtz@...>
Subject: clisp/src ChangeLog,1.7191,1.7192 zthread.d,1.72,1.73
To: clisp-cvs@...
Message-ID: <E1N5o3V-00028M-PV@...>

Update of /cvsroot/clisp/clisp/src
In directory ddv4jf1.ch3.sourceforge.com:/tmp/cvs-serv8119/src

Modified Files:
        ChangeLog zthread.d
Log Message:
(initialize_thread_bindings): allocate per thread value cell for symbols that do not have one


Index: zthread.d
===================================================================
RCS file: /cvsroot/clisp/clisp/src/zthread.d,v
retrieving revision 1.72
retrieving revision 1.73
diff -u -d -r1.72 -r1.73
--- zthread.d 3 Nov 2009 21:10:32 -0000 1.72
+++ zthread.d 4 Nov 2009 22:10:14 -0000 1.73
@@ -169,17 +169,19 @@
       var object pair=Car(*initial_bindings);
       if (consp(pair) && symbolp(Car(pair))) {
         var object sym = Car(pair);
-        /* only if the symbol already has per thread value cell.
-           we do not want to add new one here. */
-        if (TheSymbol(sym)->tls_index != SYMBOL_TLS_INDEX_NONE) {
-          /* look in the stack whether we have already bound this symbol */
-          var gcv_object_t *top = &STACK_0;
-          for (;bottom != top && !eq(*top,sym); top skipSTACKop 1) ;
-          if (bottom == top) { /* not found */
-            pushSTACK(sym); bind_count++; /* push the symbol */
-            eval(Cdr(pair)); /* maygc */
-            Symbol_thread_value(STACK_0) = value1;
+        /* look in the stack whether we have already bound this symbol */
+        var gcv_object_t *top = &STACK_0;
+        for (;bottom != top && !eq(*top,sym); top skipSTACKop 1) ;
+        if (bottom == top) { /* not found */
+          pushSTACK(sym); bind_count++; /* push the symbol */
+          /* if the symbol does not have per thread value cell - add one */
+          if (TheSymbol(sym)->tls_index == SYMBOL_TLS_INDEX_NONE) {
+            pushSTACK(pair);
+            add_per_thread_special_var(sym); /* maygc */
+            pair = popSTACK();
           }
+          eval(Cdr(pair)); /* maygc */
+          Symbol_thread_value(STACK_0) = value1;
         }
       }
       *initial_bindings = Cdr(*initial_bindings);

Index: ChangeLog
===================================================================
RCS file: /cvsroot/clisp/clisp/src/ChangeLog,v
retrieving revision 1.7191
retrieving revision 1.7192
diff -u -d -r1.7191 -r1.7192
--- ChangeLog 4 Nov 2009 16:33:16 -0000 1.7191
+++ ChangeLog 4 Nov 2009 22:10:13 -0000 1.7192
@@ -1,3 +1,8 @@
[phone]  Vladimir Tzankov  <vtzankov@...>
+
+ * zthread.d (initialize_thread_bindings): allocate per thread value
+ cell for symbols that do not have one
+
 2009-11-04  Sam Steingold  <sds@...>
 
  * eval.d (interpret_bytecode_): fix a type error in the last patch




------------------------------

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

------------------------------

_______________________________________________
clisp-cvs mailing list
clisp-cvs@...
https://lists.sourceforge.net/lists/listinfo/clisp-cvs


End of clisp-cvs Digest, Vol 43, Issue 5
****************************************

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
clisp-devel mailing list
clisp-devel@...
https://lists.sourceforge.net/lists/listinfo/clisp-devel

[Don Cohen-12]

I notice in recent clisp-cvs Digests changes to bind -per-thread
"non-global" special variables.
I've now removed the defvar I had to add because such vars had not
been bound per thread, and just want to report that the code seems
to be working.

I guess this can now be removed from the doc for make-thread:
  Note that symbols should be global SPECIAL variables (e.g.,
  declared as such by DEFVAR, DEFPARAMETER, etc).
BTW, I assume that a variable in this list is bound as a special even
if it was never declared as such, similar to progv, right?

I also noticed in the same patch changes to
MT:*DEFAULT-SPECIAL-BINDINGS* which I thought were strange.
Why is gensym counter in that list?
This is going to make debugging more difficult.
I suggest instead that gensym should use its own critical section.

I assumed that the initial thread is created with -per-thread bindings
from MT:*DEFAULT-SPECIAL-BINDINGS* but experimentation suggests
otherwise.
So I guess in that particular thread a plain setf can be used to
change the "global" values of variables.
This might be worth mentioning in the doc.

What do you think of trading
 (MT:SYMBOL-VALUE-THREAD symbol thread)
for
 (MT:GLOBAL-VALUE symbol)
and making SYMBOL-VALUE mean the -per-thread value if there is one?

My goal here is for code using SYMBOL-VALUE and originally written
for non threaded implementations to run in a new thread without
modification.  I think that this proposal corresponds better to the
normal meaning of symbol-value than the current implementation.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
clisp-devel mailing list
clisp-devel@...
https://lists.sourceforge.net/lists/listinfo/clisp-devel

[Vladimir Tzankov]

On 11/5/09, Don Cohen <don-sourceforge-xxz@...> wrote:
> BTW, I assume that a variable in this list is bound as a special even
> if it was never declared as such, similar to progv, right?

yes.

> I assumed that the initial thread is created with -per-thread bindings
> from MT:*DEFAULT-SPECIAL-BINDINGS* but experimentation suggests
> otherwise.

yes it is.
What problems have you observed?

> What do you think of trading
>  (MT:SYMBOL-VALUE-THREAD symbol thread)
> for
>  (MT:GLOBAL-VALUE symbol)
> and making SYMBOL-VALUE mean the -per-thread value if there is one?

MT:SYMBOL-VALUE-THREAD is mostly useful for debugging/inspecting
what's going on in other threads (and it is setf-able).
SYMBOL-VALUE returns what the thread "sees" at the moment (either
binding in thread if any, or global).

> My goal here is for code using SYMBOL-VALUE and originally written
> for non threaded implementations to run in a new thread without
> modification.  I think that this proposal corresponds better to the
> normal meaning of symbol-value than the current implementation.

What you mean by "normal meaining of symbol-value"?
If you use initial-bindings for special variables you are interested
in - SYMBOL-VALUE will never see symbol's global value.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
clisp-devel mailing list
clisp-devel@...
https://lists.sourceforge.net/lists/listinfo/clisp-devel

[Don Cohen-12]

 > > I assumed that the initial thread is created with -per-thread bindings
 > > from MT:*DEFAULT-SPECIAL-BINDINGS* but experimentation suggests
 > > otherwise.
 > yes it is.
After further experimentation I believe this and also that things
do work as I was suggesting, i.e., that symbol-value does use the
thread binding if there is one.
I think this should be mentioned in the doc.
I had the impression that symbol-value only read the value cell from
the symbol, which I (still) gather is the "global" value.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
clisp-devel mailing list
clisp-devel@...
https://lists.sourceforge.net/lists/listinfo/clisp-devel

[Sam Steingold]

Don Cohen wrote:
> I think this should be mentioned in the doc.

ptc

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
clisp-devel mailing list
clisp-devel@...
https://lists.sourceforge.net/lists/listinfo/clisp-devel

[Don Cohen-12]

Sam Steingold writes:
 > Don Cohen wrote:
 > > I think this should be mentioned in the doc.
 > ptc

 Bindings of dynamic variables (via LET/LET*/MULTIPLE-VALUE-BIND) are
 local to MT:THREADs, i.e.
Also progv, defun, defmethod, ... what else?  Perhaps "etc." would do.

Following is not actually true, as I understand it.
 every SYMBOL has a different value cell in each MT:THREAD.
Only those symbols naming special variables that have been bound in
a given thread have value cells in that thread.

 MT:SYMBOL-VALUE-THREAD can be used to inspect and
 modify these thread local bindings.
In fact, symbol-value can also be used to inspect and change the value
in the current thread.

I see that even the definition
 extent n. the interval of time during which a reference to an object,
 a binding, an exit point, a tag, a handler, a restart, or an
 environment is defined.
assumes a single threading model.

See how you like this:

 Bindings of dynamic variables via LET, DEFUN, PROGV, etc. are
 local to the threads in which the binding form executes.
 SYMBOL-VALUE refers to the cell holding the current binding of the
 symbol in the current thread (the one executing SYMBOL-VALUE) if the
 symbol has a dynamic binding in that thread when SYMBOL-VALUE executes.
 Otherwise it refers to the global value cell of the symbol.

It occurs to me to also mention (assuming it's correct?) BOUNDP,
that is, change above
 SYMBOL-VALUE refers
to
 SYMBOL-VALUE and BOUNDP refer

 MT:SYMBOL-VALUE-THREAD can be used to inspect and modify ...
Perhaps that could be shortened to just
See MT:SYMBOL-VALUE-THREAD.

The doc below for MT:SYMBOL-VALUE-THREAD raises a few more questions.
- Why does it distinguish between the symbol having never been bound
  and having been bound but then MAKUNBOUND when there is no such
  distinction (as far as I know) in the common lisp spec?
- The same seems to apply to distinguishing between bound in the thread
  and only bound globally.
- What does it return for the value if the symbol is unbound?
- Perhaps by analogy there ought to be MT versions of BOUNDP and
  MAKUNBOUND?
Finally, aren't all these things (other than the distinctions
mentioned above) equivalent to various calls on MT:THREAD-INTERRUPT ?
Does MT:SYMBOL-VALUE-THREAD have to wait for the same opportunity to
interrupt?


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
clisp-devel mailing list
clisp-devel@...
https://lists.sourceforge.net/lists/listinfo/clisp-devel

[Vladimir Tzankov]

On 11/6/09, Don Cohen <don-sourceforge-xxz@...> wrote:
>  Bindings of dynamic variables via LET, DEFUN, PROGV, etc. are
Not DEFUN. Only symbols value cells can be thread specific.

> The doc below for MT:SYMBOL-VALUE-THREAD raises a few more questions.
> - Why does it distinguish between the symbol having never been bound
>   and having been bound but then MAKUNBOUND when there is no such
>   distinction (as far as I know) in the common lisp spec?

I came to this issue while adding support for clisp in
portable-threads and implemented it like in:
http://www.franz.com/support/documentation/current/doc/operators/mp/symeval-in-process.htm

Note that symbol-value-thread does not return the same values as if
symbol-value is called in the thread. If the symbol is not bound in
thread it will return (NIL,NIL) but the thread itself will use global
value (i.e. symbol-value executed in thread will return the global
value).

symbol-value-thread is mostly useful for inspecting running threads
without interrupting them.

> Finally, aren't all these things (other than the distinctions
> mentioned above) equivalent to various calls on MT:THREAD-INTERRUPT ?
symbol-value-thread cannot be implemented via thread-interrupt - from
lisp not all internals are accessible.

> Does MT:SYMBOL-VALUE-THREAD have to wait for the same opportunity to
> interrupt?
No - it does not suspend/interrupt the thread.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
clisp-devel mailing list
clisp-devel@...
https://lists.sourceforge.net/lists/listinfo/clisp-devel

[Don Cohen-12]

Vladimir Tzankov writes:
 > On 11/6/09, Don Cohen <don-sourceforge-xxz@...> wrote:
 > >  Bindings of dynamic variables via LET, DEFUN, PROGV, etc. are
 > Not DEFUN. Only symbols value cells can be thread specific.
Defun also binds variables and these can be special.

 > > The doc below for MT:SYMBOL-VALUE-THREAD raises a few more questions.
 > > - Why does it distinguish between the symbol having never been bound
 > >   and having been bound but then MAKUNBOUND when there is no such
 > >   distinction (as far as I know) in the common lisp spec?
 >
 > I came to this issue while adding support for clisp in
 > portable-threads and implemented it like in:
 > http://www.franz.com/support/documentation/current/doc/operators/mp/symeval-in-process.htm

Which only makes me wonder why they decided to expose this distinction.

 > Note that symbol-value-thread does not return the same values as if
 > symbol-value is called in the thread. If the symbol is not bound in
 > thread it will return (NIL,NIL) but the thread itself will use global
 > value (i.e. symbol-value executed in thread will return the global
 > value).
I understand, but again this falls under the category of exposing
distinctions that the cl spec does not.

 > symbol-value-thread is mostly useful for inspecting running threads
 > without interrupting them.
I understand.

 > > Finally, aren't all these things (other than the distinctions
 > > mentioned above) equivalent to various calls on MT:THREAD-INTERRUPT ?
 > symbol-value-thread cannot be implemented via thread-interrupt - from
 > lisp not all internals are accessible.
 >
 > > Does MT:SYMBOL-VALUE-THREAD have to wait for the same opportunity to
 > > interrupt?
 > No - it does not suspend/interrupt the thread.

In that case I'd expect either that access to the thread local
storage is protected by critical sections, or that it sometimes
returns "incorrect" results (values that never would have been
returned had the critical section been implemented).
I suppose it's possible that it could be written in such a way
that the hardware supplies the necessary critical section, but
I'd have to understand the processors better in order to convince
myself of that.  (I'd be interested in the details though.)

In any case, this seems to be an important difference between
symbol-value-thread and what could be done with thread-interrupt.
I'd be tempted to describe symbol-value-thread in terms of the
approximately equivalent thread-interrupt implementation but with
the additional note that it is more efficient in that it does not have
to actually interrupt the thread or even wait for the thread to reach
a point where it could be interrupted.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
clisp-devel mailing list
clisp-devel@...
https://lists.sourceforge.net/lists/listinfo/clisp-devel