The subject basically says it all.
I am under the impression that the reason threads only work on Linux
x86 has more to do with x86 and less to do with Linux. If this is the
case, will threading on x86-based Macs be easy to get going? Has
anyone with a x86 mac dev box tried to get SBCL up and running?
Justin Dubs
<······@gmail.com> wrote:
> The subject basically says it all.
>
> I am under the impression that the reason threads only work on Linux
> x86 has more to do with x86 and less to do with Linux. If this is the
> case, will threading on x86-based Macs be easy to get going?
It'll be easier than getting it to work on powerpc, but not quite
trivial.
Although these days SBCL mostly uses pthreads instead of the the
native Linux clone(2) for implementing threads, it uses futexes (fast
userspace mutexes) for locking instead of pthread facilities. Darwin
doesn't have a futex-like API, and (IIRC) all the pthread locking
primitives have some properties that make the difficult to use
instead of futexes.
> Has anyone with a x86 mac dev box tried to get SBCL up and running?
Not as far as I know.
--
Juho Snellman
"Premature profiling is the root of all evil."
Juho Snellman wrote:
> <······@gmail.com> wrote:
> > The subject basically says it all.
> >
> > I am under the impression that the reason threads only work on Linux
> > x86 has more to do with x86 and less to do with Linux. If this is the
> > case, will threading on x86-based Macs be easy to get going?
>
> It'll be easier than getting it to work on powerpc, but not quite
> trivial.
>
> Although these days SBCL mostly uses pthreads instead of the the
> native Linux clone(2) for implementing threads, it uses futexes (fast
> userspace mutexes) for locking instead of pthread facilities. Darwin
> doesn't have a futex-like API, and (IIRC) all the pthread locking
> primitives have some properties that make the difficult to use
> instead of futexes.
Thanks for the information.
I just checked out the newest SBCL from CVS. It looks like it's really
just condition-wait and condition-notify in src/code/target-thread.lisp
that are the problem.
It seems like you could emulate futexes using pthreads without much
trouble. You'd need a mutex + an int. So, it'd be heavier and slower.
Plus, there's the comedic value of emulating futexes with pthreads
given that futexes are used to implement pthreads on linux.
Maybe there is more to it than that. I haven't thought about this for
very long.
Thoughts?
> > Has anyone with a x86 mac dev box tried to get SBCL up and running?
>
> Not as far as I know.
Ok. Well, if and when I get my hands on an x86 Mac, I'll try.
Justin Dubs
<······@gmail.com> wrote:
> It seems like you could emulate futexes using pthreads without much
> trouble. You'd need a mutex + an int. So, it'd be heavier and slower.
> Plus, there's the comedic value of emulating futexes with pthreads
> given that futexes are used to implement pthreads on linux.
>
> Maybe there is more to it than that. I haven't thought about this for
> very long.
It goes something like this (sorry for the vagueness, threads aren't
exactly my area of expertise):
* Memory for the mutexes should be automatically managed
* Posix semaphores may not be moved around in memory, so they
can't be allocated in GCd space
* Allocating the mutexes in non-GCd space and ensuring their
timely destruction with finalizers is a bad idea because of
mumble mumble can't quite remember what the problem was.
Now, possibly mumble mumble isn't too bad if the option is having no
thread support at all, or the GC could be changed to recognize
semaphore objects and not move them, etc. But it won't be just a
matter of enabling :SB-THREAD and rebuilding.
--
Juho Snellman
"Premature profiling is the root of all evil."
Juho Snellman wrote:
> <······@gmail.com> wrote:
> > It seems like you could emulate futexes using pthreads without much
> > trouble. You'd need a mutex + an int. So, it'd be heavier and slower.
> > Plus, there's the comedic value of emulating futexes with pthreads
> > given that futexes are used to implement pthreads on linux.
> >
> > Maybe there is more to it than that. I haven't thought about this for
> > very long.
>
> It goes something like this (sorry for the vagueness, threads aren't
> exactly my area of expertise):
>
> * Memory for the mutexes should be automatically managed
> * Posix semaphores may not be moved around in memory, so they
> can't be allocated in GCd space
> * Allocating the mutexes in non-GCd space and ensuring their
> timely destruction with finalizers is a bad idea because of
> mumble mumble can't quite remember what the problem was.
>
> Now, possibly mumble mumble isn't too bad if the option is having no
> thread support at all, or the GC could be changed to recognize
> semaphore objects and not move them, etc. But it won't be just a
> matter of enabling :SB-THREAD and rebuilding.
Thanks a lot for the clarification. That's a much more complicated
problem than I had hoped it would be...
Justin Dubs
From: =?utf-8?b?R2lzbGUgU8ODwqZsZW5zbWk=?= =?utf-8?b?bmRl?=
Subject: Re: SBCL with threads on Intel Macs?
Date:
Message-ID: <0nmzkgv47e.fsf@kaktus.ii.uib.no>
Juho Snellman <······@iki.fi> writes:
> <······@gmail.com> wrote:
> > It seems like you could emulate futexes using pthreads without much
> > trouble. You'd need a mutex + an int. So, it'd be heavier and slower.
> > Plus, there's the comedic value of emulating futexes with pthreads
> > given that futexes are used to implement pthreads on linux.
> >
> > Maybe there is more to it than that. I haven't thought about this for
> > very long.
>
> It goes something like this (sorry for the vagueness, threads aren't
> exactly my area of expertise):
>
> * Memory for the mutexes should be automatically managed
> * Posix semaphores may not be moved around in memory, so they
> can't be allocated in GCd space
> * Allocating the mutexes in non-GCd space and ensuring their
> timely destruction with finalizers is a bad idea because of
> mumble mumble can't quite remember what the problem was.
>
> Now, possibly mumble mumble isn't too bad if the option is having no
> thread support at all, or the GC could be changed to recognize
> semaphore objects and not move them, etc. But it won't be just a
> matter of enabling :SB-THREAD and rebuilding.
If I understand this and other postings in this thread, the lack of thread-support
on systems others than x86-linux has not really anything with processor
architecture to do, but is rather a question about which thread primitives
that is available in the OS. Is that right?
--
Gisle Sælensminde, Phd student, Scientific programmer
Computational biology unit, BCCS, University of Bergen, Norway,
Email: ·····@cbu.uib.no
If I had more time, I would have written a shorter letter. (Blaise Pascal)
Gisle Sælensminde wrote:
> If I understand this and other postings in this thread, the lack of thread-support
> on systems others than x86-linux has not really anything with processor
> architecture to do, but is rather a question about which thread primitives
> that is available in the OS. Is that right?
On x86 non-linux systems it's the question of finding a substitute for
futexes. On platforms other than x86 (and x86-64) the bulk of the work
is porting gencgc that is a prerequisite for threads.
See http://sbcl-internals.cliki.net/Threading-ppc and
http://sbcl-internals.cliki.net/GENCGC-ppc
Gábor Melis
> --
> Gisle Sælensminde, Phd student, Scientific programmer
> Computational biology unit, BCCS, University of Bergen, Norway,
> Email: ·····@cbu.uib.no
> If I had more time, I would have written a shorter letter. (Blaise Pascal)