[Ecls-list] MP stability improvement

[Juan Jose Garcia-Ripoll]

Hi Matthew,

let me try to answer your your email without quoting your message, just to
make it all more readable.

* The basic problem is that due to what I believe is a design flaw, mutexes
offer no API to query their status. This is a problem because a call to a
mutex lock may be interrupted by a user who unwinds the stack to an outer
point (using a restart) leaving ECL without means to record that the call
indeed succeeded. This means that making the calls to get-lock and
giveup-lock atomic is impossible.

* I believe the right algorithm for with-lock would be

1 - variable error_code = not_owned
2 - begin unwind-protect region
3 -- error_code =  pthread_mutex_lock()
4 -- if not error_code execute user code
5 - exit unwind-protect region
6 -- if no error_code
7 --- error_code = pthread_mutex_unlock()
8 --- if error_code != not owned signal error
9 -- end if
a - end unwind-protect

The problem we have right now is that steps 3 and 7 are implemented using
Lisp routines that consist on more than just a call to
pthread_mutex_[un]lock(). They can be interrupted and the output variables
not match at all the desired values (error_code would have the wrong value)

* This all arises, as I say, from the fact that we export get-lock for the
user. A possible safer alternative would be to implement WITH-LOCK as

(defmacro with-lock ((lock &rest options) &body body) `(mp:do-with-lock
#'(lambda () , at body) ,lock , at options))

and let MP:DO-WITH-LOCK be a C function that implements steps 1-a above.
What do you think?

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20120211/a59a167d/attachment.html>