Steel Bank Common Lisp

rif <rif@...> writes:

> I'm using SBCL (0.9.13, x86 linux) and I'm observing something that
> seems odd to me.  I load a foreign library and call a foreign function
> that itself calls dlopen.  It seems that if I set LD_LIBRARY_PATH to
> include the path to the internally dlopen'd library BEFORE I started
> sbcl (in emacs with M-x setenv), everything works fine.  However, if I
> instead wrap the C function setenv and use that to set LD_LIBRARY_PATH
> from within SBCL, the internal call to dlopen fails --- it complains
> that it can't find the library.  Any ideas what would cause this
> phenomenon?  Right now, the workaround I have is to ensure that the
> other library resolves via other system mechanisms (e.g. ldconfig), but
> I'm curious as to what's going on.

Offhand, I'd guess that the dynamic loader (the Linux one) takes
a look at LD_LIBRARY_PATH when the program starts, and remembers it.

Just a guess, though.

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."

Greetings SBCL Folks,

In SBCL, is there a way to wait on a condition variable/signaling 
mechanism without requiring a mutex?  I could acquire and release a 
thread-local mutex for each cv-wait, but I'd rather skip the locking 
overhead if possible.

Thanks for your time,
David

No, I don't think there is such thing. Maybe it is not a condition 
variable that you need. You can implement other primitives with mutex 
and condition variables, but you will still have the overhead.

But here is a nice, inventive, and powerfull (even if a little wicked 
and bit naughty) way to do something like that. Why don't you use a 
mutex to simulate what you want? Do a SB-THREAD:MAKE-MUTEX followed by a 
SB-THREAD:GET-MUTEX. Now, the following SB-THREAD:GET-MUTEX blocks a 
thread (more or less a CONDITION-WAIT) and SB-THREAD:RELEASE-MUTEX 
signals the blocked thread (more or less a CONDITION-NOTIFY). Two things 
you must pay attention to: SB-THREAD:GET-MUTEX needs an argument, or it 
might signal an error telling that a thread is trying to get the mutex a 
second time (of course we know that everything is OK, right?), or 
something vastly worse; and SB-THREAD:GET-MUTEX must be called before 
SB-THREAD:RELEASE-MUTEX. This is mad, of course, and I would never do 
anything like it, but maybe you can use it in some way.

One other thing is that futex implementation of condition variables is 
broken. It will be better in a couple of weeks.

Marco

David L. Rager wrote:
> Greetings SBCL Folks,
> 
> In SBCL, is there a way to wait on a condition variable/signaling 
> mechanism without requiring a mutex?  I could acquire and release a 
> thread-local mutex for each cv-wait, but I'd rather skip the locking 
> overhead if possible.
> 
> Thanks for your time,
> David
> 
> 
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Sbcl-help mailing list
> Sbcl-help@...
> https://lists.sourceforge.net/lists/listinfo/sbcl-help
>

Hello Marco,

Thank you for your thoughts. 

Unfortunately, I don't think the mutex hack will work, because there is 
sometimes a one-to-many relationship between the signaling thread and 
the waiting threads.

Also, thanks for the heads up about the instability of CV's right now.  
While we're talking, I'll mention that I've thought about submitting a 
timed version of condition-wait as a suggested patch.  In OpenMCL, my 
application eventually frees up OS resources by letting threads expire 
after 60 seconds, but there's currently no such mechanism in SBCL.

Thanks,
David

Marco Monteiro wrote:
> No, I don't think there is such thing. Maybe it is not a condition 
> variable that you need. You can implement other primitives with mutex 
> and condition variables, but you will still have the overhead.
>
> But here is a nice, inventive, and powerfull (even if a little wicked 
> and bit naughty) way to do something like that. Why don't you use a 
> mutex to simulate what you want? Do a SB-THREAD:MAKE-MUTEX followed by a 
> SB-THREAD:GET-MUTEX. Now, the following SB-THREAD:GET-MUTEX blocks a 
> thread (more or less a CONDITION-WAIT) and SB-THREAD:RELEASE-MUTEX 
> signals the blocked thread (more or less a CONDITION-NOTIFY). Two things 
> you must pay attention to: SB-THREAD:GET-MUTEX needs an argument, or it 
> might signal an error telling that a thread is trying to get the mutex a 
> second time (of course we know that everything is OK, right?), or 
> something vastly worse; and SB-THREAD:GET-MUTEX must be called before 
> SB-THREAD:RELEASE-MUTEX. This is mad, of course, and I would never do 
> anything like it, but maybe you can use it in some way.
>
> One other thing is that futex implementation of condition variables is 
> broken. It will be better in a couple of weeks.
>
> Marco
>
> David L. Rager wrote:
>   
>> Greetings SBCL Folks,
>>
>> In SBCL, is there a way to wait on a condition variable/signaling 
>> mechanism without requiring a mutex?  I could acquire and release a 
>> thread-local mutex for each cv-wait, but I'd rather skip the locking 
>> overhead if possible.
>>
>> Thanks for your time,
>> David
>>
>>
>> Using Tomcat but need to do more? Need to support web services, security?
>> Get stuff done quickly with pre-integrated technology to make your job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Sbcl-help mailing list
>> Sbcl-help@...
>> https://lists.sourceforge.net/lists/listinfo/sbcl-help
>>
>>     
>
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Sbcl-help mailing list
> Sbcl-help@...
> https://lists.sourceforge.net/lists/listinfo/sbcl-help
>

Hi Everyone,

In your opinion, is the futex implementation of CV's still broken?  It seems
to be working in 0.9.15, but if it is still broken, I'd be interested in
knowing how I can break it.

Thanks for a great x86 multithreaded LISP!
David

-----Original Message-----
From: Marco Monteiro [mailto:masmon@...] On Behalf Of Marco Monteiro
Sent: Monday, June 26, 2006 6:59 PM
To: David L. Rager
Cc: sbcl-help@...
Subject: Re: [Sbcl-help] Lockless Condition Variable Waiting

One other thing is that futex implementation of condition variables is 
broken. It will be better in a couple of weeks.

Marco

Hello David.

Two threads are running. Thread 1 calls function CONDITION-WAIT and is 
preempted immediately after releasing the mutex and before calling 
FUTEX-WAIT. Thread 2 acquires the mutex, calls CONDITION-WAIT on the 
same condition variable and blocks. Now, when thread 1 is scheduled 
again, it will not block because WAITQUEUE-DATA has changed.

This is not a major problem; it is a 'spurious wakeup' that can be 
solved with the (loop until (something-p) do (condition-wait q m)) 
pattern. I think I saw a real [big] problem with the implementation, but 
I do not remember what it was.

Marco

David L. Rager wrote:
> Hi Everyone,
> 
> In your opinion, is the futex implementation of CV's still broken?  It seems
> to be working in 0.9.15, but if it is still broken, I'd be interested in
> knowing how I can break it.
> 
> Thanks for a great x86 multithreaded LISP!
> David
> 
> -----Original Message-----
> From: Marco Monteiro [mailto:masmon@...] On Behalf Of Marco Monteiro
> Sent: Monday, June 26, 2006 6:59 PM
> To: David L. Rager
> Cc: sbcl-help@...
> Subject: Re: [Sbcl-help] Lockless Condition Variable Waiting
> 
> One other thing is that futex implementation of condition variables is 
> broken. It will be better in a couple of weeks.
> 
> Marco
> 
>