[gambit-list] SMP status

Adam adam.mlmb at gmail.com
Mon Nov 13 10:58:25 EST 2017


Wow!

(I'll try to start using the correct terminology "processor" for "OS
thread" and "thread" for "green thread", soon.)

2017-11-13 21:41 GMT+08:00 Marc Feeley <feeley at iro.umontreal.ca>:
[..]

> For I/O, there may be missing locks to ensure that separate processors
> don’t do I/O on a port at the same time.  I haven’t tested this thoroughly.
>

(At least the user code-facing Gambit IO routines, have looked since before
to me like having the locking well implemented. And I guess now those same
mutex locks, are automatically SMP-safe - err, I should ask about that
below. So you must mean some kind of runtime-internal locking here somehow.)

Is |mutex-lock!| SMP-safe now - also without costing much more now than
before?

If the SMP-safe |mutex-lock!| is more expensive only: is there then any
variant that would only work between green threads within one and the same
OS thread.

> Can I do TCP/console/file IO from any OS & green thread, or from some
> particular one, which and how do I ensure that?
>
> Keeping all I/O in a single thread is definitely the safest scenario to
> avoid locking issues. Just assign these tasks to a single thread. All other
> threads should not do I/O.
>

Wait - say you do console IO in one OS thread, TCP IO in one OS thread, and
file IO in one OS thread - how could that be a problem?

Also, when you say it's best to assign the IO tasks to one thread, do you
mean one OS thread or one green thread - if one OS thread, then, how do I
stick and unstick a given set of green threads (ordinary thread objects) to
be executed in one particular OS thread only?



> > (http://www.iro.umontreal.ca/~gambit/doc/gambit.html#Threads says
> "Gambit supports the execution of multiple Scheme threads. These threads
> are managed entirely by Gambit’s runtime and are not related to the host
> operating system’s threads. Gambit’s runtime does not currently take
> advantage of multiprocessors (i.e. at most one thread is running).", will
> need update.)
>
> Will update when this is no longer true.  I view --enable-smp as
> experimental…
>
> I need feedback from people using SMP to weed out problems.
>

Noted.

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20171113/a526c3d9/attachment.htm>


More information about the Gambit-list mailing list