In the last episode (Mar 27), Mirar @ Pike developers forum said:

While Pike is doing something that might be taking some time, it can run other Pike-threads in the foreground. This is done in a lot of operations, all of those you mention, I believe - all that make sense.

So if you are doing a lot of image operations, it will use several real threads for the operations.

Any place in C code that you see THREADS_ALLOW / THREADS_DISALLOW pairs, that's where the code has released the main pike interpreter lock, allowing other threads to run.

I'm not quite sure what you mean.

Any code within a THREADS_ALLOW()/THREADS_DISALLOW() pair can be executed simultainiously in multiple threads on multiple cores. They only release the interpreter lock so that another thread may execute Pike-code.

Thus, many modules that glue C-libraries into Pike will have THREADS_ALLOW()/DISALLOW() statements around the actual call to the library it wraps, allowing other threads to execute while the library is called.

In the cases where wrappers don't do this, it's not unlikely that the wrapped library isn't thread-safe and thus would require separate locking if the interpreter lock was released.

(I failed to notice replies earlier due to unexpected mail filtering - oops.)

-----Oorspronkelijk bericht----- Van: pike-devel-bounces@lists.lysator.liu.se [mailto:pike-devel-bounces@lists.lysator.liu.se] Namens Mirar @ Pike developers forum Verzonden: Monday, March 30, 2009 9:50 AM Aan: pike-devel@lists.lysator.liu.se Onderwerp: Re: (semi-)multicore support?

This uses two threads, two cores if your OS runs threads on different cores:

Pike v7.8 release 205 running Hilfe v3.5 (Incremental Pike Frontend) | > void test() { for (;;) { Image.Image i=Image.Image(1000,1000); | string s=Image.JPEG.encode(i); } }

| > Thread.Thread(test); | (1) Result: Thread.Thread(1079527760) | > Thread.Thread(test); | (2) Result: Thread.Thread(1080490320)

It is limited to two OS threads (one for Pike, one for libraries, or maybe one for each library), or does it have the possibility of one OS thread per library call (theoratically resulting in X OS threads, which might or might not be faster here if the system has more than two cores)?

Regards,

Arjan

__________________________________________________________ Deze e-mail en de inhoud is vertrouwelijk en uitsluitend bestemd voor de geadresseerde(n). Indien u niet de geadresseerde bent van deze e-mail verzoeken wij u dit direct door te geven aan de verzender door middel van een reply e-mail en de ontvangen e-mail uit uw systemen te verwijderen. Als u geen geadresseerde bent, is het niet toegestaan om kennis te nemen van de inhoud, deze te kopieren, te verspreiden, bekend te maken aan derden noch anderszins te gebruiken.

The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Please notify us immediately if you have received it in error by reply e-mail and then delete this message from your system. __________________________________________________________

Okay, so it appears it's not likely to gain much anymore for C-libraries because the interpreter lock is being released where possible already, allowing it to run on separate cores at that point. What if the 'C-library' is another instance of Pike? Could it be (made) possible to have Pike release it's interpreter locks if it would be known to not have any inter-Pike processing there anyway?

Say, there is a function implemented in Pike which could be very CPU-intensive and only handles locally created variables. I can imagine some definition which would tell Pike which variables are interfacing between the two instances, after which instance #1 and instance #2 do their own separate processing (and interpreter locking) without interfering with the other instance until it has data to return (if any).

Regards,

Arjan

__________________________________________________________ Deze e-mail en de inhoud is vertrouwelijk en uitsluitend bestemd voor de geadresseerde(n). Indien u niet de geadresseerde bent van deze e-mail verzoeken wij u dit direct door te geven aan de verzender door middel van een reply e-mail en de ontvangen e-mail uit uw systemen te verwijderen. Als u geen geadresseerde bent, is het niet toegestaan om kennis te nemen van de inhoud, deze te kopieren, te verspreiden, bekend te maken aan derden noch anderszins te gebruiken.

The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Please notify us immediately if you have received it in error by reply e-mail and then delete this message from your system. __________________________________________________________

On Tue, Mar 31, 2009 at 02:15:04PM +0000, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:

the only way to pass data between them would be through pipes or the shared memory interface, which only can pass strings. You could just as well run several pike processes.

the Remote interface provides support for passing more elaborate datastructures.

it could be interesting to have an interface that looks like threads but essentially runs multiple processes and hides the multiprocess communication from the user.

starting a 'thread' would create a new process and run the given function, using Remote to pass data between the 'threads'

i think the result would be the same as pythons multiprocessor module.

greetings, martin.

isn't any datastructure in memory in the end a string of bytes?

so what kind of string is meant here?

greetings, martin.

ah, i see, well, of course i didn't think such a multiprocess support would replace threading, when the advantage of threads is being able to share datastructures, but it could be interesting for situations where the threads are heavy workers that don't need to communicate much data.

a version of roxen that spreads over all available cpu's for example. i guess similar cases are on arjans mind too.

arjan, you could just look at pikes Remote module and take some ideas from pythons multiprocessing module to achive the effect you are asking for.

greetings, martin.

On Wed, Apr 01, 2009 at 05:04:36PM +0200, Arjan van Staalduijnen wrote:

...

arjan, you could just look at pikes Remote module and take some ideas from pythons multiprocessing module to achive the effect you are asking for.

Thanks, I will definitely take a look at it.

without having looked myself, i am hoping that it should be possible to have a simple Remote server that can just accept functions or objects to run.

then in the main application only some code is needed to either start up such a Remote server, or manage a pool of already running instances.

greetings, martin.

It is limited to two OS threads (one for Pike, one for libraries, or maybe one for each library), or does it have the possibility of one OS thread per library call (theoratically resulting in X OS threads, which might or might not be faster here if the system has more than two cores)?

To put it another way:

Pike always have one OS - pthread_create, _beginthread, etc - thread per thread, it just that it can't run more than one of the threads at a time in the interpreter.

The rest will be waiting for the interpreter lock, unless they are doing something that doesn't need it, like image- or file operations. In those cases they release the interpreter lock, so other threads can grab it. It will more or less look like this:

real thread started: lock(the interpreter lock) forever do pike calculations and variable operations

while doing this, sometimes (function call, loopbacks, etc) unlock(the interpreter lock) // let other interpreter threads run lock(the interpreter lock)

in some functions, like Image.JPEG.encode or file read: unlock(the interpreter lock) do the heavy stuff // let other interpreter threads run lock(the interpreter lock)

So it's not limited, but every Pike thread will use up real thread resources like stack address space. (This is a problem if you plan on having an application with 1000 threads.)