Professional OPC
Development Tools

logos

Online Forums

Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.

Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.

Do not use the Contact page for technical issues.

Threading

More
27 Oct 2011 13:53 #582 by support
Replied by support on topic Re: Threading
In COM, in 3.0x and 5.0x/5.1x versions, there is no SynchronizationContext property, and the event notifications always come on a thread that is created by the component. It is equivalent to having SynchronizationContext == null in .NET.

Please Log in or Create an account to join the conversation.

More
27 Oct 2011 13:43 #581 by owe@eurosys.se
Replied by owe@eurosys.se on topic Re: Threading
Thanks
Do you remeber how it worked in version 3.0, eg EasyDACom?
>Owe

Please Log in or Create an account to join the conversation.

More
27 Oct 2011 13:36 #580 by support
Replied by support on topic Re: Threading
There are two scenarios:
If the SynchronizationContext on the EasyDAClient object is null, then the events are raised on an internal thread (i.e. it is guaranteed it is not any of the other threads you have in your application). In such case, if you block in that thread, it does not affect those other threads; it only stops more notifications from coming. You may spin up new thread in this scenario, if you have a need for it - but you do not have to do it in other to keep the rest of your app performing well.
If the SynchronizationContext on the EasyDAClient is set to non-null, then the even notifications go through that SynchronizationContext object. What that means in relation to threads is up to the specific class of SynchronizationContext that is used. If, for example, your code is a Windows Forms application, and you set the SynchronizationContext to the current context when the form is initialized, then this particular SynchronizationContext for Windows Forms class guarantees that you will be able to manipulate controls on the form (which is otherwise not guaranted to work from just any generic thread - it must be the UI thread). In effect, however, this means that now the event notification is happening on the UI thread, and blocking in it will stop the other UI in your application. In this scenario, to prevent it, you would spin up a new thread to do the blocking work.

Please Log in or Create an account to join the conversation.

More
27 Oct 2011 13:10 #579 by owe@eurosys.se
Threading was created by owe@eurosys.se
Hi!

Is there any need for me to spin up new threads when "ItemChanged" get triggered using EasyDAClient. As I understand the event is raised on unique threads from EasyDAClient anyway so there want be any stocking on a single thread in my service, or?

>Regards Owe

Please Log in or Create an account to join the conversation.

Moderators: support
Time to create page: 0.053 seconds