[armedbear-ticket] [armedbear] #135: ql:FEB2011:bordeaux-threads BORDEAUX-THREADS does not work

[armedbear]

#135: ql:FEB2011:bordeaux-threads BORDEAUX-THREADS does not work
------------------------+---------------------------------------------------
  Reporter:  mevenson   |       Owner:  mevenson                          
      Type:  defect     |      Status:  accepted                          
  Priority:  major      |   Milestone:  0.25                              
 Component:  libraries  |     Version:  0.24                              
Resolution:             |    Keywords:  bordeaux-threads quicklisp threads
------------------------+---------------------------------------------------
Changes (by mevenson):

  * status:  new => accepted


Comment:

 A quick description of what I think is going on here:

 http://slack.net/~evenson/abcl/bordeaux-threads-abcl-20110227a.diff
 contains the current version of my against the b-t git trunk.

 The g-t trunk:

   * [http://common-lisp.net/gitweb?p=projects/bordeaux-threads/bordeaux-
 threads.git;a=commitdiff;h=314e67cbe309c3b1b2e9a95f47c7c0a7fb8a52b7 fix
 the move of threads from EXT to THREADS]

   * [http://common-lisp.net/gitweb?p=projects/bordeaux-threads/bordeaux-
 threads.git;a=commitdiff;h=ee279a45320762840efc3b3efc1b835e50c5f6fd gives
 THREAD-YIELD a reasonable value]

 But this is not enough, as at some time in the past (???) we removed
 !ThreadLock.java which contained support for THREAD-LOCK and THREAD-
 UNLOCK, although we (BUG!) still autoload these symbols.

 My patch then:

    * removes the use of the built-in (and from what I can make of it
 really rather deprecated) condition variables implementation, substituting
 one based on the built-in JVM synchronization primitives

    * provides a new implementation of the lock based on the
 [http://download.oracle.com/javase/6/docs/api/java/util/concurrent/locks/ReentrantLock.html
 java.util.concurrent.locks.ReentrantLock].  This structure is general
 enough to implement both the recursive and non-recursive locks abstracted
 by the b-t interface. The b-t maintainer (Stellian) has critiqued the lack
 of proper guard against using these two types, which I have agreed need to
 be addressed in the code with more explicit checks.

 With these patches, b-t passes all but one of its built-in tests.

 There are style complaints on compilation that seem to indicate that the
 test suite is not being properly initialized.

-- 
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/135#comment:1>
armedbear <http://common-lisp.net/project/armedbear>
armedbear