S-Lang and threading
Doctor D
interpreter is thread safe? For instance, if I embed the interpreter
in my app and call SLang_load_string(<program>) on multiple threads it
seems to me that things will get hairy pretty fast as Slang should be
restarted if any of these return -1 and all intrinsic vars and fns
should be reloaded. Do I have the right impression here?
Thanks in advance for any info or tips on how this might be safely
multiplexed out, does the interpreter have to be global, can an
instance be instantiated at a function call?
John E. Davis
wrote:
> I think I know the answer to this already but does anyone know if the
> interpreter is thread safe? For instance, if I embed the interpreter
> in my app and call SLang_load_string(<program>) on multiple threads it
The interpeter is reentrant but not thread safe. That is, you can
have a call SLang_load_string, which may in turn call
SLang_load_string, but you cannot call the interpreter from multiple
threads.
Early on, I experimented with threads. But the overhead of passing
the thread state around was killing the performance of the most common
case (single thread). I considered adding python-like pseudo threads,
but I never found that very interesting.
[...]
> Thanks in advance for any info or tips on how this might be safely
> multiplexed out, does the interpreter have to be global, can an
> instance be instantiated at a function call?
If you can set the problem up as a master-slave one, where the slaves
do not communicate among themselves, then fork can be used. This is
the approach adopted by the isis spectral modeling program
<http://space.mit.edu/cxc/isis/>. If you want use threads to perform
simultaneous files from the web, then you can use the curl module. It
really depends upon the problem.
What are you trying to do?
Thanks,
--John
Doctor D
Genetic Algorithm will produce programs using Grammatical Evolution
that can then be executed by the SLang interpreter and make various
callbacks to a simulator. The great thing about GAs is that
individuals can be evaluated in parallel, which lead me to using
threads and multiplexing the evaluation process. A fork would work but
there would be work involved in pulling back in the fitness from the
simulation and syncing everything once the generation is done. I think
ideally a separate sandbox for each call to load a program would work
best
On Mar 9, 11:45 pm, "John E. Davis" <j...@jedsoft.org> wrote:
> On Tue, 9 Mar 2010 20:13:25 -0800 (PST), Doctor D <>
John E. Davis
wrote:
> Interesting. I'm incorporating SLang into an evolutionary system, so a
> Genetic Algorithm will produce programs using Grammatical Evolution
> that can then be executed by the SLang interpreter and make various
> callbacks to a simulator. The great thing about GAs is that
> individuals can be evaluated in parallel, which lead me to using
> threads and multiplexing the evaluation process. A fork would work but
> there would be work involved in pulling back in the fitness from the
> simulation and syncing everything once the generation is done. I think
> ideally a separate sandbox for each call to load a program would work
> best
One of the fitting algorithms in isis <http://space.mit.edu/cxc/isis/>
is a monte-carlo search algorithm. Here, N fits are executed in
parallel at N different starting locations. Another use of
parallelization occurs when evaluating multi-dimensional confidence
limits. This amounts to performing a number of fits in parallel using
the same objective function. Both of these tasks involve forking
slaves to evaluate the spectral models (objective or fitness
functions). The communication with the slaves is message based and is
handled via the socket module. This works out quite well and keeps
all the CPU cores quite busy.
There is a simple example of this at
<http://space.mit.edu/cxc/isis/multicore_example.html>. You can run
this example in slsh if you get
<http://www.jedsoft.org/tmp/fork_socket.sl>
<http://www.jedsoft.org/tmp/multicore_example.sl>
Just make sure that fork_socket.sl is in the same directory as
multicore_example.sl. Then do:
slsh ./multicore_example.sl
The forking of the slaves and the socket-based communication with them
is contained in fork_socket.sl. It seems to me that this should also
meet your needs.
I hope this helps.
Thanks,
--John
Doctor D
I'm looking to do.
On Mar 10, 11:04 pm, "John E. Davis" <j...@jedsoft.org> wrote:
> On Wed, 10 Mar 2010 19:03:21 -0800 (PST), Doctor D <ian.demp...@gmail.com>