2011/3/21 Chun Tian (binghe) binghe.lisp@gmail.com:
Hi, Mark
The problem definition in the pdu.lisp is this two:
#-portable-threads (defmethod generate-request-id ((pdu common-pdu)) (with-slots (request-id-counter) pdu (the (unsigned-byte 32) (logand (incf request-id-counter) #xffffffff))))
#+portable-threads (defmethod generate-request-id ((pdu common-pdu)) (with-slots (request-id-counter) pdu (the (unsigned-byte 32) (logand (portable-threads:atomic-incf request-id-counter) #xffffffff))))
The only difference between two versions, is the use of INCF being replaced to ATOMIC-INCF, which is a thread-safe version of INCF.
If I always use the first version in ABCL (there's another similar method in message.lisp), than ABCL can pass this, and directly goes to the second issue (it's definitely CLOS related, I think)...
I wrote some basic extension code for GBBopen's portable-threads.lisp to support threading in ABCL (no cond var), and the form
(portable-threads:atomic-incf request-id-counter)
will be macro-expanded into
(PORTABLE-THREADS:AS-ATOMIC-OPERATION (INCF REQUEST-ID-COUNTER 1))
then
(PORTABLE-THREADS:WITH-LOCK-HELD (PORTABLE-THREADS::*ATOMIC-OPERATION-LOCK*) (INCF REQUEST-ID-COUNTER 1))
and then (simplified)
(THREADS:WITH-MUTEX (PORTABLE-THREADS::*ATOMIC-OPERATION-LOCK*) (INCF REQUEST-ID-COUNTER 1))
Consider ATOMIC-INCF itself works just right. I think maybe ABCL compiler cannot handle a macro form inside method definition quite well, shouldn't be CLOS/MOP's fault.
I don't think this has anything to do with CLOS at all, it's probably some bug in the compilation of the logand form.