Re: some ideas for multithreading support

I'm not as familiar with the details as the others commenting on this
thread, so maybe you could give me some ideas where to look for
answers to a few questions.

 > > *Every object access* will have to be protected by taking a lock.

What qualifies as an object?
A fixnum?  That's immutable, right?  So I expect no lock is needed.
How about a cons cell?
Under what circumstances could two threads accessing a cons cell 
cause a crash or any illegal lisp data?
I can see that garbage collection is a special case, but I thought
it already was handled in some way (which I'd be happy to learn more
about).
If two threads are not in GC and they are only either reading the
car or cdr of a cons cell or replacing it with some legitimate value,
and these are atomic operations, I don't see the problem.
What am I missing?
(Is a pointer on your stack something you can write into a cons cell?
If so, this seems as much a problem without MT as with it.)

I imagine that other objects are similar to cons cells in the sense
above, except that they might have some non-atomic operations that
have to be protected by locks.
Is that all correct?  If so, the issue becomes identifying the 
operations that have to be protected.

 > > I don't know what the status on this task is, but I expect that this
 > > will severely limit the set of target platforms for multithreading to
 > > glibc and few other systems.

I'm guessing that the glibc issue is that different libraries used
by clisp offer the "same" facilities but they're thread safe in some
libraries but not others.  And glibc tends to be more thread safe than
the others.  Is that correct?  So you might have to stop using some
libraries or replace certain operations in them with thread safe versions.
Sounds pretty painful, I admit.  Not to mention maintenance as these
libraries evolve.

 > > This too will limit the set of target platforms. In the end, I expect
 > > that only modern glibc, Windows, and macOS will be left as target
 > > platforms for multithreading.
 > 
 > which is sad because one of the salient features of clisp is
 > portability.

However it's not so bad when some feature that's not so portable was
not part of the standard to begin with.  Clisp has other platform
dependent features.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel