[Scilab-users] threading model in Scilab 6 (alpha)

[jasper van baten]

Hi François,

Many thanks for your reply. As soon as you know more, I would be very 
pleased to test again in a new alpha. I would like to have my software 
back up-and-running before the actual release of Scilab 6. Before doing 
so I will have to decide how to handle the threading issue.

If the solution will be that all is single threaded but in different 
threads, I suppose my best work-around would still be to synchronize 
access to the underlying objects over a private thread. I hope you will 
decide to keep the core thread alive and recycle it between calls, so 
that all calls are made on the same thread.

If on the other hand your solution will be full multi-threaded 
execution, I would welcome that too. Also in this case I hope you will 
create a fixed number of threads and recycle them, for the same reason. 
In this case I can simply create a corresponding number of COM objects 
under the hood.

I am not sure why events from outside the thread would have to make that 
you stop the thread and start another one (unless you forcefully 
terminate the thread, but I suppose you do not as this will surely lead 
to memory leaks and other trouble). You can simply set up your 
calculation thread to do something like

void core_threadproc() {

  for (;;) {
     //wait until next command
     synchronizationObject.wait();
     //pick up next (set of) command(s) and execute
     if (nextCommand==CommandTerminate()) break;
     ...

   }

}

For interrupting calculations you could poll between individual commands 
and during length commands.

On another note: removal of the intersci exe forced me to switch to the 
api-scilab (short of keeping previous builds of scilab around). I am 
pleased with this interface, it is a lot nicer than intersci. The C++ 
interface is nicer than the C interface, I think, but does not seem to 
have support for strings and some other data types (unless I missed 
something). So I am now mixing my approach: "csci" interfaces for all 
routines that take string matrices as in- our output, and "cppsci" 
interfaces for all routines that only deal with numeric matrices. 
Support for string (and other) data types from the cppsci interface 
would be welcome in the future.

Best wishes,

Jasper



On 8/5/2015 10:21, François Granade wrote:
> Hi Jasper,
>
> Looks like you have found an interesting question here...
>
> First - there are no multiple concurrent threads in the core. So we 
> are safe (and so is the API, without being thread-safe).
>
> However, what you saw is right: each command executes in a new thread. 
> We designed it on purpose, with one of the reason being that this 
> thread can be what we call the "storeCommand" which manages events 
> from outside the main thread (UI, interruption). Another idea was that 
> - later - to allow multithreaded execution (under some serious 
> constraints).
>
> Now, your point about COM loading, and thread-local storage, is very 
> valid, and may very well mean that we should change this.
>
> We will study if/how we could modify that... we'll keep you posted.
>
> Thanks *a lot* for reporting this; it's exactly what we released the 
> alpha for, and even though we were hoping we would not have such 
> questions, it's better to have them now than later...
>
> for the Scilab team,
> François Granade
>
>
>
> On Aug 4, 2015, at 9:21 AM, jasper van baten <jasper at amsterchem.com 
> <mailto:jasper at amsterchem.com>> wrote:
>
>> Does anybody know what threading model is used in Scilab 6 alpha? I 
>> am referring to the default mode of operation, and not while 
>> executing parallel_for, or MPI as described here 
>> (http://wiki.scilab.org/Documentation/ParallelComputingInScilab).
>>
>> If there are multiple core threads that execute concurrently, then 
>> all api-scilab code needs to be written in a thread-safe re-entrant 
>> safe manner. I doubt this is the case.
>>
>> If there is one core thread alive at any point, it would make sense 
>> for this to remain the same thread, which does not appear to be the 
>> case. If not the same thread, any application that depends on 
>> apartment threaded COM objects or thread local storage will no longer 
>> function as it did in Scilab 5. The solution may be to synchronize 
>> such applications over a private thread, but that surely will come at 
>> a performance cost.
>>
>> Having some idea about the threading model that is intended and used 
>> would be helpful.
>>
>> Best wishes,
>>
>> Jasper.
>>
>> On 7/31/2015 18:35, jasper van baten wrote:
>>> All,
>>>
>>> What's the story with threading in Scilab 6? Whereas previous 
>>> versions appeared to be single threaded from an external DLL point 
>>> of view, I see that the DLLmain function gets called by a one 
>>> thread, whereas interface routines get called from another thread. 
>>> Worse, looks like each interface routine call is made from a new 
>>> thread. What is the threading model?? Is there a limited number of 
>>> threads, or are threads created on the fly?
>>>
>>> Thanks, best wishes,
>>>
>>> Jasper
>>>
>>>
>>> _______________________________________________
>>> users mailing list
>>> users at lists.scilab.org
>>> http://lists.scilab.org/mailman/listinfo/users
>>
>> _______________________________________________
>> users mailing list
>> users at lists.scilab.org <mailto:users at lists.scilab.org>
>> http://lists.scilab.org/mailman/listinfo/users
>
>
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20150805/9fd4c309/attachment.htm>