3

I'm trying to use stmx inside the lparallel infrastructure.

This simple snippet raises an exception:

(ql:quickload :stmx)
(ql:quickload :lparallel)

(setf lparallel:*kernel* (lparallel:make-kernel 4))

(lparallel:future
  (stmx:atomic (format t "~a ~%" "it works")))
Unhandled SIMPLE-ERROR in thread #<SB-THREAD:THREAD "lparallel" RUNNING {1003F8F073}>:
  STMX internal error!
  stmx:*current-thread* contains a stale value:
   found #<SB-THREAD:THREAD "main thread" RUNNING {1004DC01F3}>
   expecting #<SB-THREAD:THREAD "lparallel" RUNNING {1003F8F073}>
Typical cause is:
   new threads were created with implementation-specific functions,
   as for example (sb-thread:make-thread) or (mp:process-run-function),
   that do not apply thread-local bindings stored in
   bordeaux-threads:*default-special-bindings*
Solution:
   use (bordeaux-threads:make-thread) instead.

The problem is obvious: it seems that lparallel starts a native sbcl thread, while stmx relies on bordeaux-threads to function correctly.

And indeed, this one fixes an error (though it is a total nonsence):

(lparallel:future
  (bt:make-thread
   (lambda ()
     (stmx:atomic (format t "~a ~%" "it works")))))

The question is: how to make lparallel spawn bordeaux-threads? is it even possible? or is there another workaround?

Update

following @Svante's proposal i've tried to bind stmx.lang:*current-thread* to actual lparallel current thread, and surprisingly it works:

(defmacro lpar-atomic (&body body)
  `(let ((stmx.lang:*current-thread* (lparallel.thread-util:current-thread)))
     (stmx:atomic ,@body)))

(lparallel:future
  (lpar-atomic (format t "~a ~%" "it works!")))

It seems to be a workaround, still it is kind of ugly. If someone has an idea how to do it in general, i'd be glad. Otherwise we probably need to 'fix' stmx somehow )

5
  • I am a bit confused, because looking at the source it seems that lparallel is already using bordeaux-threads. Commented Sep 29, 2021 at 12:23
  • @Svante , yes i also thought i saw it somewhere.. But it works this way.. first i thought it could be related to sly mrepl, but sbcl --load ./some.lisp --disable-debugger acts the same. I think i have the latest versions from quicklisp (2021-08-07), sbcl 2.1.9 Commented Sep 29, 2021 at 12:27
  • 1
    I think this might be an issue in stmx. It never re-binds its *current-thread* - maybe you need to re-bind it yourself? Commented Sep 29, 2021 at 12:30
  • @Svante, hmm.. i will try to do it later in the evening. Does it look like a library bug to you? Commented Sep 29, 2021 at 13:06
  • 1
    Not sure, Maybe ask there? Commented Sep 29, 2021 at 14:34

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.