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

jasper van baten jasper at amsterchem.com
Wed Sep 9 09:00:58 CEST 2015 

Hi François,

Perfect - yes that would work great for me. Is there an update on the 
alpha available that has this change?

Strings: nice. I am impressed with the API interface.

Best wishes,

Jasper.

On 9/8/2015 19:49, François Granade wrote:
> hi Jasper,
>
> Yes, we made a decision - and in fact we implemented it already: and 
> we changed it to be simply always use the same thread. That should 
> work for you, right ?
>
> Regarding your other question (api scilab): I believe that there is 
> string support for cpp (we implemented it), however this is still in 
> development, and may still change before the release...
>
> François Granade
>
>
> On Sep 3, 2015, at 4:51 PM, jasper van baten <jasper at amsterchem.com 
> <mailto:jasper at amsterchem.com>> wrote:
>
>> 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
>>
>> _______________________________________________
>> 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/20150909/412f7f92/attachment.htm>

More information about the users mailing list