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

[jasper van baten]

Hi François,

Is there a decision on the threading model yet?

Many thanks, best wishes,

Jasper.

On 8/5/2015 10:44, jasper van baten wrote:
> 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> 
>> 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
>
>
>
> _______________________________________________
> 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/20150903/b0c37fed/attachment.htm>