Page 1 of 1

Priorities of threads

Posted: Tue Jan 24, 2017 1:17 pm
by SergE
I have vision panel, containing many instances of a certain faceplate.
Panel initialization script of faceplate has a following structure:

Code: Select all

main()
{
  dyn_string dpeList;
  . . .   // init consts, dpeList etc.

  dpConnect("callBackFunc",dpeList);  // (answer=true)

  if(dynlen(getLastError())==0)
  { 
     ...   // Additional initialisation 
           // (for instance, create and install events handlers scripts
           // for several graphic objects, etc)
           // Can occupy certain time.
  }
  else
  {
     ...   // visualize symbols error
  }
}

// work function:
void callBackFunc(dyn_string dpeList, dyn_anytype val)
{
  ...  // paints, animate of graphics objects of symbol primitive,
       // depending on current condition.
  setMultiValue(...);
}
I have noticed, that execution (in realtime) of
work functions and additional initialization (after dpConnect) in my computer occurs
consecutively, with minimal switching timeslice.
Herewith, additional initialization interfere work functions and increase their time performance.
How I can raise the priority of work functions respecting additional initialization?
In other words, all panels work functions must be completed before continue any additional
initialization after dpConnect() call.

Re: Priorities of threads

Posted: Tue Jan 24, 2017 2:13 pm
by RudiKreiner
Doing it something like this should help:

Code: Select all

bool init = FALSE;

main()
{
  dpConnect("work",....

  whille(!init)
    delay(1);

  // continue initialization here
}

work()
{
  // do your work here
  init = TRUE;
}

Re: Priorities of threads

Posted: Tue Jan 24, 2017 2:49 pm
by SergE
Thank you, i assumed this, but wanted to control priority of thread directly, or always have work functions thread priority above than other threads.

Re: Priorities of threads

Posted: Tue Jan 24, 2017 4:17 pm
by RudiKreiner
I don't think that there is any way of doing that (at least as far as I know of), but maybe someone from ETM can confirm that or give further tips.

Re: Priorities of threads

Posted: Wed Jan 25, 2017 7:37 am
by zheleschikovav
Use semaphore functions.

Code: Select all


bool init = FALSE;

main()
{
  dyn_string dpeList;
  . . .   // init consts, dpeList etc.

  dpConnect("callBackFunc",dpeList);  // (answer=true)

  semAcquire("callBackFunc_done"); // wait for semRelease("callBackFunc_done");
  init = TRUE;

  if(dynlen(getLastError())==0)
  { 
     ...   // Additional initialisation 
           // (for instance, create and install events handlers scripts
           // for several graphic objects, etc)
           // Can occupy certain time.
  }
  else
  {
     ...   // visualize symbols error
  }
}

// work function:
void callBackFunc(dyn_string dpeList, dyn_anytype val)
{
  ...  // paints, animate of graphics objects of symbol primitive,
       // depending on current condition.
  setMultiValue(...);

  if (!init) semRelease("callBackFunc_done");
}

PS "while() delay(1)" bad practice.

Re: Priorities of threads

Posted: Wed Jan 25, 2017 7:57 am
by fmulder
This discussion is an example of over complicating a WinCC OA project. The first question should be :

* Why do you think that there is a problem ?
* What graphical effect do you see ?

I've implemented many panels in OA with many different icons and I've never needed a mechanism like this. I'd guess that your're making a principal mistake. Please explain what you are trying to achieve.

Normally each icon is a separate entity. It fires a dpConnect() and does its own drawing. It should not matter that other icons are doing the same thing. I've never seen a situation where an icon needs to wait for other icons or where the panel needs to wait for all icons to initialize.

On our developers laptops we have situations that might seem similar. Normally the icons is part of a bigger framework and it could be using/needing global variables. Example: we store the user permissions in a global variabele (becuase userPermissionForArea() is a slow function). Unfortunately, when you place the icon on a panel and run the panel, then the global variabels will not have the right values. You can not implement a panel A, containing icons, and call 'UsersInit()' from the EventInitialize because it could happen that the EventInitialize of the icon is faster

The solution for our laptops:
Create a panel B that calls 'UsersInit(()" and then open panels A containing the icon. Or, make sure that the globals are setup and then open the panels that need them

Re: Priorities of threads

Posted: Wed Jan 25, 2017 10:11 am
by SergE
What graphical effect do you see ?
Perceptible deceleration of coloration at presence some any massive code after dpConnect().
(Whole panel have many (100-200) instances of one icon)
Why do you think that there is a problem ?
I need minimize visual coloration speed of panels after their starts
( specially, on stodgy panels). if i delete any code after dpConnect(), the panel
loaded more quickly. But also i need automatize event handling, drag-drop settings and popup controls
in complex faceplates (by means of common mode library functions). This require great thread presence after dpConnect().

On my observations, after dpConnect() the script is simultaneously splitting on two threads with equal priority. One is a work function, second is remained part of script. Usually, remained part is small, and no problem. In other case this may be a problem, because all icons threads presumably is not handling simultaneously, but everyone thread have any small slot time to execute consecutively. Since all threads are equivalent, accelerate more considerable threads is not possible.

Re: Priorities of threads

Posted: Wed Jan 25, 2017 10:18 am
by fmulder
If the loading of your panel is a problem, then why do you load it ?

Or, why don't you load the panel earlier and only hide it. You could show your panel in an embedded module and switch your module to invisible.

p.s. 100 - 200 icons is not many ! We have seen panels with much more icons. Maybe your icons are too complex. Normally icons are relatively simple and do not have a lot of script code to draw something.

Re: Priorities of threads

Posted: Wed Jan 25, 2017 10:38 am
by mkoller
I have seem problems with slow icon display when the user configured very large images but they should be displayed in small objects
so the UI manager had to always scale them down.
Better use images which match the size of your objects so no scaling is needed.

Re: Priorities of threads

Posted: Wed Jan 25, 2017 10:42 am
by SergE
Yes, my icons are slightly mad, but it is a customer requirement.