There is one thing more that needs doing for SBCL/pthreads: futex#

Sun, 06 Mar 2005 00:13:13 +0000

There is one thing more that needs doing for SBCL/pthreads: futex removal. It looks like we can almost replace them with POSIX 1003.1b semaphores, but for one small problem

<dan-b> I feel a sudden need to say ARGH ARGH ARGH
<dan-b> I wonder what happens if GC moves a waitqueue struct while threads are waiting on it
<pfdietz> 'Bad Things'?
<dan-b> I can think of no reason for that not to be the case, certainly
<dan-b> maybe it just never happens because there's a reference to the struct on the stack of one or more of the participating threads
<dan-b> from the arglist to get-mutex or whatever
<dan-b> actually I could believe that
<dan-b> | Only sem itself may be used for performing synchronisation. The result of referring to copies of sem in calls to semwait(), semtrywait(), sempost(), and semdestroy(), is undefined
<dan-b> looks like pthreads is going to have bigger problems, though
<dan-b> even unlocked semaphores are now immovable

(quote is from the sem_init specification)

waitqueue was a perfectly ordinary struct. I think I'm going to have to make it a primitive object so that I can teach GC how to move it safely (semdestroy, move, seminit in new location). Sigh. Or keep the semaphores in not-lisp-memory, and account for them by hand. Or initialise them when first needed (when something wants to wait) and destroy them again as soon as all threads are no longer waiting. Or go to bed and see if any better ideas occur to me tomorrow.