xsharp.eu

Hi Robert, Chris and all Forum guys,

today I was doing some learning about 'GO' the language, and it made me wonder just what facilities there are in the .NET modern Framework for handling (writing) concurrency into our code.

According to the YouTube guy there is a subtle but major difference between parallel coding and Concurrency.

Have any of you guys tried any GO coding as yet ?

TIA,
Phil.

Hi Phil,

A quick search shows this:

https://docs.microsoft.com/en-us/dotnet ... oncurrency
https://msdn.microsoft.com/en-us/librar ... .110).aspx

sounds very interesting, but to be honest I have not used those features myself (yet).

Chris

Hi Chris, hi Phil,

some time ago I wrote a sample for asyncron processes:

https://www.riedmann.it/download/AsyncApp.zip

It is a small WPF application that starts a simple asyncron process. And yes, it uses a BlockingCollection object from the System.Collections.Concurrent namespace.

Wolfgang

Thanks Wolfgang,

I will look into this as Meinhard wants me to cover in some way Blocking and Asynchronicity with my session on "Arrays to Collections" at Cologne 2018.

Is Concurrency in .NET what we have been calling 'Async' coding ?

Speak soon,
Phil.
Wales, UK.

Hi Phil,

at least the two links Chris has posted lead to this functionality.
I had looked at them and remembered that I hat written something a few months ago (as a test for myself).
In WPF unfortunately you need something like this otherwise your GUI will freeze until the process terminates. It is not like WinForms or VO GUI where you can call a function to give processing to the GUI ( ApplicationExec( EXECWHILEVENT ) in VO per example.

If you are populating a DataGrid from a collection that is refreshed from a background process there is another caveat: sometimes the DataGrid will give a runtime error that the number of elements is different from the effective collection size.

Wolfgang

Wolfgang Riedmann wrote:Hi Phil,
If you are populating a DataGrid from a collection that is refreshed from a background process there is another caveat: sometimes the DataGrid will give a runtime error that the number of elements is different from the effective collection size.

Hi Wolfgang,

This sounds like an ObservableCollection... there's a basic rule that you mustn't use another thread to add/remove items from ObservableCollections that are used on the UI thread. It took me a while (and a lot of runtime errors!) to realise this.

It's not really a problem though... typical scenario is refreshing data from a database or adding a newly created item. So the slow bit is getting data from the db - run that asynchronously, then simply apply the update to the collection on the UI thread after the awaited method has completed.

I believe there are ways now to handle OCs from other threads, but I haven't investigated.

Nick

Hi Nick,

This sounds like an ObservableCollection... there's a basic rule that you mustn't use another thread to add/remove items from ObservableCollections that are used on the UI thread. It took me a while (and a lot of runtime errors!) to realise this.

exactly. In my case it is a server monitor that requests pages from a remote server and displays the times on a DataGrid.

I suspected something like this, but had not the time to investigate further.

I have planned to do this in a background service process and use the GUI application only to display the data from the local SQLite database - but unfortunately I'm short on time all the time <g>.

This is the exact error message:
Wolfgang

Hi Nick,

a quick search on Google gave this for example:

https://stackoverflow.com/questions/23108045/how-to-make-observablecollection-thread-safe

I like the fact that I'm can use all the tips and recipes from the large C# community!

Wolfgang

Hi Wolfgang,

I'd be a bit wary of solutions like that. I found the best thing was to simply work within the basic design paramters and refactor the code to avoid updating collections on the background thread. If you move the slow processes into asynchronous methods, then call those with await from your UI thread, when the awaited method returns you can safely update your ObservableCollection.

I now do this everywhere, and the UI is 100% smooth and we get no updating errors.

There are loads of modified observablecollection classes, and I've tried several at one time or another, but they all have issues. The other classic is getting existing objects in a collection to update - there are subclasses that supposedly handle this, but in the end it's best to work with WPFs design logic and make sure you implement INotifyPropertyChanged properly on the objects in the collection.

That's my experience at least.

Nick

Hi Nick,

thank you very much for your precious advice!

Wolfgang