Concurrency Utilities in .NET

Today I have great fun in my HIT8197 Advanced .NET lab. We decided to do some group programming in order to create "the" bounded channel for .NET. For those of you who are not familiar with this concept you can read about it on SwinBrain.

The one thing that is often overlooked in .NET concurrent programming is the Interrupt exception on the enterring a lock.

I will write more on this tomorrow...

Below I have attached the outline of the architecture for the Murray Bookshop applications that the students of HIT8099 have been working with. Any comments are very welcome...

Message Based Architecture of the Murray Bookshop

The Murray Bookshop is a “virtual company” that forms the basis of the Enterprise .NET subject at Swinburne University of Technology. Students of HIT8099 extend the application, with each semester building on the previous semester. The bookshop has been running for one year and currently includes a web site that allows customers to browse the products on offer, and place and track orders. A Windows application is used by warehouse staff to fill orders, order shipping, and mark orders as collected. As this is a virtual company, a Windows service is provided to simulate employees and customers. This service places orders and performs warehouse operations at timed intervals.

This document outlines the core architecture used in this project. This architecture is designed with several key areas namely: layered architecture, stateless business components, message based communication, and loosely coupled components.

Layered Architecture

Applications built for the Murray Bookshop use a layered architecture consisting of a presentation layer, business layer, and data access layer. The architecture used is based upon the recommendations in Microsoft's Patterns and Practices book titled Application Architecture for .NET: Designing Applications and Services available at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/distapp.asp .

Implementation Notes:
Database access is not available to the presentation layer components.

Stateless Business Components

The Murray Bookshop uses stateless business components to help avoid concurrency issues at the business layer. This also helps reduce issues related to access via the web, as these components are typically accessed via a web application, or web service.

Implementation Notes:
Avoid instance variables within business components.
Use local variables for interacting with database components (as these contain state information).
Do not use Business Entities.

Message Based Communication

Messages are used for communication between components across layers. To facilitate this, a set of classes has been included in the core assemblies. These classes contain the details sent to the service to make a request, and returned from the service in response to this request. This simplified the process of changing the communication channel used as these classes are Serializable and encapsulate all information to be exchanged between parties

Implementation Notes:
The Murray.Core.Common.Messages namespace contains the message classes.
Each service offered by the bookshop has a Request (Message) and a Response .

The FetchCustomerOrderMessage is used to request customer orders to view on the accounts page of the web site. This request is sent from the web application to the IManageOrders component when then generates a FetchCustomerOrderResponse , which is then returned to the caller. The FetchCustomerOrderMessage contains the details required to make this request including the customer's code, the order status filter (indicates all orders, outstanding orders, or previous orders), as well as the page requested, and the records per page. The FetchCustomerOrderResponse contains the response from this request. The response contains the requests details, the total number of pages, and a dataset with the results.

Several parts of all requests will be consistent across all requests and responses. For a request message this includes the page requested, the records per page, and also a search filter (not used in this example). For the response this includes the requests details, and the total number of records. This functionality is encoded in the BaseSelectRequest and BaseSelectResponse .

Future Considerations/Changes:

Currently the individual message classes are contained within the core assembly. This reduces the ability to work on the individual projects in isolation. This location is currently used as these classes are needed in the database, business, and presentation layers. If this was reduced to the presentation and business layer the classes could be located in application assemblies rather than the core assemblies.

With .NET 2.0 generics will allow more functionality to be moved into the base class messages. This may allow all message to use just these base classes, though requests will then require a Parameters class (example).

Loosely Coupled Components

The business components are only accessible via interfaces. The user of these classes loads the component via the ComponentLoader and GenericFactory classes. For example the OrderManagementService implements the IManageOrders interface. This class can be loaded via the OrderManagerLoader 's Load method. This method reads the assembly and class details from the associated app.config file, loads this assembly and then constructs an object of the configured class.

This structure allows for communication between the presentation and business layer to be changed. During testing locally installed business components can be directly used, while in production a proxy can be installed locally that communicates with the application server. Additionally this allows for changes to be made to business components without requiring modifications to the user interfaces. This will allow easier deployment of bug fixes and minor business changes.

Implementation Notes:
The current applications include an adapter that used COM+/Enterprise Services to allow communication between the presentation layer on the web server and business layer on the application server.

Windows ME -> Longhorn?

A friend of mine raised the question "will Longhorn be the Windows ME of the XP Era?". This is an interesting perspective.

Tips and Tricks

Over the last week I have been reading a number of articles on .NET development, and was thinking on what I should do with the information I had read. What I wanted was to keep track of what I had learnt. My ideas were: 1: Write a Review of each article, 2: Add an entry to my blog.

I decided not to do 1 as I didn't want to do a full review of each article, I just wanted some notes to help me remember it and a link to refer back to it. I decided against 2 as well, as I don't really want to sort through both my blog entries to find information on that one article you want.

In the end I decided to create a new blog just for these tips and tricks. My plan is to use this as a repository for links to articles that I find useful, and a record of what was useful from the article.

If you are intereted the link is http://www.thoughtlabs.net/andrew/tipsandtricks

Examining the UPC Framework

Today I started looking into making changes to Microsoft's User Process Component Application Block. I am writing this blog entry so that I can remember what I have learnt...

The framework is as appears in the image here (from the UPC Application Block help).

As you can see, the UPC block centers around the idea of screen navigation. The coordinating class (in terms of the block) here is the Navigator. Developers provide the functionality for the Application (Your Application) the Controller (Your Controller) and the views (Your Views). The Navigator coordinates the transition between views.

One error on this diagram is the link between the Controller Base and the State. This is actually contained within the Navigator (i.e. the ControllerBase asks the Navigator for the State information). So the Navigator contains the state.

The navigator is loaded based on the information in the navigationGraph node in the Config file, or from the use of Open Tasks.

Goal: Remove the link from Your Views to Your Controllers.
Reason: Increase the reusability of Your Views, and the flexibility of Your Controllers.

Ideas:
Views have a specific purpose. Views can use and store information in State objects. A View which is accepting information from the user should store the supplied information in the State before propogating action requests.

Views can initiate actions (i.e. button clicks). Actions are received by a framework component and routed to the Controller, thereby avoiding the direct connection. The view has access to the Navigator (also not in the diagram), and so this can act as the Coordinator.

Concentrating on the Navigation Graph style for the moment:
Currently the graph has Nodes that have navigateTo links. These specify the destination view for a given action. For example:

<navigationgraph>
    <node view='Form1'>
        <navigateto navigatevalue='next' view='Form2'/>
    </node>

    <node view='Form2'>
        <navigateto navigatevalue='previous' view='Form1'>
        <navigateto navigatevalue='finish' view='Form3'/>
    </node>
</navigationgraph>

My thoughts so far suggest to replace navigateTo with a trigger node that contains one or more actions:

<navigationgraph>
    <node view='Form1'>
        <trigger value='next'>
            <navigateTo view='Form2' />
        </trigger>

    </node>
    <node view='Form2'>
        <trigger value='previous'>
            <navigateTo view='Form1'/>
        </trigger>

        <trigger value='finish'>
            <controllerAction name='updateDatabase' / >
            <navigateTo view='Form3' />
        </trigger>
    </node>

</navigationgraph>

The data for the 'updateDatabase' action would be taken from the tasks associated state information.

This allows the actions on the controller to be configured rather than hard coded.

User Process Components and State

I have had some more thoughts on user process components and thought I should try to put it into writing...

If we are to separate more completely the user interface from the processing, there still needs to be some way to share information between the user interface and the process, and visa versa. My current thoughts on this are leading me towards a more specific shared state. Let me explain.

In the current UPC (version 2), the state shared between the controller and the user interface uses a general key-value pair scheme. Both the user interface and the controller must know which keys contain which values, and which keys are manipulated by which user interface screen. This logic is not obvious from the types involved in the transaction, and so must be maintained in project documentation.

In order to further decouple the user interface from the processing, this state contract can be strengthened. Rather than using simple key value pairs, I believe that it will be better to introduce interfaces on the state information. Each of the user interface components (UIC) can then interact with one of these interfaces. The state passed into the UIC would conform to this interface, and the actions of the UIC would then guarantee that certain actions are performed upon the state passed in (view, add, update, etc.).

The User Process Component (UPC) framework would provide a base interface from which the other state interfaces would inherit. This interface would provide access to the key-value pair exposed by the state base class. More detailed interfaces would expose a more fine grain access, allowing access to specific data (possibly read only). Each interface would be designed to represent a single aspect of the state. In this way, multiple interfaces would be used on a single state item. For example you can have a IAddressInformation interface. This would be used to represent data that contains an address, such as a Customer, Order, etc. An Address form can then be created in the UICs, and can be used to manipulate address information for multiple UPC (for example Create Order, ChangeAddress, Register Customer, etc.) . As the actual processing is not within the UIC this will be very flexible.

This should be able to be implemented in the UPC version 2 framework. Something that I will have to look into soon.

Always remember to look on the bright side of life...

Blog Location

Have a look at this greate concept... Blog Locations.
My blog location is:



Have a look at http://www.csthota.com/blogmap/

XC#

Well I have tried to get XC# to work with Whidbey with no luck.

Installed ok, but when VS2005 was loaded it was unable to locate office.dll. The office.dll is used by the AddIn to interact with the command bars of Visual Studio. To fix this I modified the code so that it used the Whidbey style AddIn code to interact with the command bars, this does not require office.dll and so the AddIn now loads.

Now there is a problem with the XC# compiler. During compilation the compiler throws an exception as it is unable to load the System.Collections.Generic.Dictionary class. As I dont have the source code to this there is very little I can do...

At the moment I want to play around with Whidbey a little more, so I will delay a look at this until after I have finished playing with this.

Aspect Oriented .NET

On another of my projects I am looking at ways to help automate commonly repeated tasks. For example. In this project, all exceptions within the service layer are managed and wrapped in a custom exception. The Exception Management application block is used to publish the exceptions details. Each of the exceptions has an associated Publishable Exception, which contains the exception to be thrown beyond the service layer. This ensures that only appropriate exceptions are made public.

In order to implement this all public methods in the service layer must catch all unhandled exceptions and then throw the associated Publishable Exception. For example the code is something like this:

public void ServiceLayerMethod(Parameters p)
{
try
{
...
}
catch(Exception exc)
{
Manager.RaiseFilteredException(exc);
}
}

While this is not much code it is annoying to type, and a bigger problem if missed.

Getting this out of the code and into some form of aspect, or even attribute, has been a goal of mine for a while. This can be achieved by using ContextBound objects, but this forces the developer to inherit from this class and is not as flexible as I would like. Today I have spend some time looking into some of the other Aspect Oriented extensions for .NET. This has lead me to XC# from ResolveCorp. I have only just download the VS2005 version and will investigate it over the next few days.

Has anyone tried using this? The documentation on the site is very thin... but it does appear that I should be able to implement this as an aspect. If this is the case the plan is to create a ExceptionManaged attribute that can be applied at a class or method level. At a class level, all non-private methods will be wrapped with the exception management code.

If you have had any experience with XC# that you think will help please let me know... if not I will post up my progress as I go.

UIP Application Block

I have started reading the details about the application block (User Interface Process Application Block - Version 2). The block aims to allow you to more easily implement MVC applications where the transitions between views is flexible. The block states that it wants to make it easier to "Add new pages", etc.

The block implements much of this very well. The views are, however, coupled to the controller. On page 60 of the PDF that comes with the block it indicates "to add navigations to your view call the methods defined within your controller." This has several negative side effects.

Firstly, it is now difficult to add new views into the application. If additional steps are added to a user interface process, this requires changes to the existing views, and controller, and the addition of the new view.

Secondly, you cannot use a single view for multiple tasks. In some cases it may be possible for a single view to participate in multiple tasks. If the controller is directly called from the view this is not easy to implement.

Ideally we should be able to decouple the view from the controller. This in itself will be a complex addition as there is some coupling required between these entities. The controller is currently decoupled from the view. However, operations of the controller will require information from the view.

How this can be decoupled must be considered carefully.

Asynchronous User Interfaces

I have been thinking about this topic over the last few days. How should you build concurrency into user interface processes. In this context concurrency is used entirely to ensure responsiveness, not due to any form of concurrent nature of the application. In other words how can we gain the required responsiveness without introducing the issues related to concurrency.

As some of the previous blogs entries on this have discussed, concurrency is difficulty, with shared data being the cause of the issues. Within the user interface only limited sharing of data between threads is only required. We need to communication progress, and completion (with success or failure etc).

While I have been thinking about this in the back of my mind, I have also been reviewing some of the material I use to teach enterprise development with .NET. In particular, User Interface Process Components, see http://msdn.microsoft.com/library/en-us/dnbda/html/AppArchCh2.asp?frame=true. I think the concept of User Interface Process Components is great. The application block, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/uipab.asp, is ok but IMO lacks some basic functionality. Mainly I would liked to have see the ability to link actions to user interface events, rather than just transitions. Transitions can then become actions, multiple actions can be performed by composition. Having this reduces the functionality of the user interface components to notifying the user interface process of certain events + managing the view. The "What happens" part of the application is controlled by the user interface process.

Given this, it would be nice to have asynchronous support built into this. Given tasks (or parts of tasks) could then be marked as asynchronous. Running these tasks is then coordinated by the UIP framework. Asynchronous tasks could be given the ability to indicate progress. The coordination of data required to do this would also be managed by the framework. Basically, by using this developers will be able to gain responsiveness, without (as many) concerns for concurrency.

I haven't spent anywhere need long enough thinking about this but I am interested in any comments you have.

---

Issues I can think of off the top of my head:

1: Interaction with the UI. If a task is asynchronous the developer must not interact with GUI elements. Doing so is asking for disaster...
2: Web application. I think this will be ok but there are some tricks that need to be done to get this to work ok.

---

Just some random thoughts on this (so I don't forget):

UIC --> UIP (User interface components are dependent on User Interface Processes)

Each UIC would have a specific functionality, for example collecting data from the user and storing it in the UIP. Therefore UIP is not dependent on UIC.

UIP needs to move to new views. UIP --> UIC... UIP <--> UIC. However page transitions are already implemented in the application block. This interdependence is already present within the block.

Moving actions into UIP ensures that it is encoded here and not in the UIC.

Do you really want one UIP for web and windows? Does the extra complexity outweigh the benefits?

---

Any thoughts on this are very welcome.

Concurrency Articles

I have uploaded a couple of articles on concurrency. These are very introductory and cover race conditions, and locks.

Having written these I think I need a thread basics to introduce threading itself as a concept. The next article will cover liveness and deadlocks. I plan then to introduce other thread exclusion mechanisms, and then move onto coordinating multiple thread.

Any comments will be greatly appreciated.

Concurrent Programming

As Matthew points out on his blog, another potential solution to the concurrency issue is to stop further requests by disabling the button...

I have updated by DeadLock2.zip file to include a new fourth solution.

In this solution I have separated out the logic of the library functionality. I think I understand the intended model a little better now, and as I see it, it is responsible for echoing a stored message + some additional string. I have coded this into an "Echoer" class that internally stores the message.

Using this library, the UI requests an echo from the Echoer with the additional string "1 ". The result that is echoed is then used to update the Echoer's message property.

If you examine the solution I have uploaded, you will notice that there are no locks used. This implementation is thread safe due to the structuring of the program. Updates to the Echoer's Message property occur on the GUI thread. The worker thread is responsible for processing the echo and returning the new string. The thread safety is ensured by stopping the GUI thread from interacting with this variable until after the transaction is completed.


So why the differing views?

There are two perspectives on this issue. When I read the code originally I was viewing it from a concurrency mindset. Therefore you look for potential cases of concurrency and try to determine all of the potential race conditions. The fix to this issue is then to modify the library to include thread safety mechanisms. Thereby ensuring that the library will be usable in a concurrent environment.

We can also consider this from the perspective of an application developer using a non-thread safe library object. In this case the responsibility of ensuring thread safety lies in the UI, as the library cannot be changed.


And the motto of the story is?
Writing good concurrent programs is not hard... it is very hard. A slight oversight and you will have introduced unexpected bugs. These bugs are not the friendly kind that will appear in testing, these are the nasty kind that only show up on rare occasions (in my experience this is usually when it is critical that the don't show up).

One of the most important things to consider with any of these solutions is communication. How do you communicate that the line "button1.Enabled = false;" is absolutely critical to the safety of the application? If this line is removed, the safety of the application is compromised. In a team development environment you need to ensure that there is a good understanding of the strategies used to ensure that the application remains safe and live.

Patterns can help greatly with communication. I am really looking forward to seeing Matthew's future entries on this topic...

On Invoke and BeginInvoke
Basically I agree with Matthew, BeginInvoke is usually the better option. However, I would not go as far as saying that Invoke should never be used. Rather, it is my opinion that you should understand what you are trying to do and choose the one that is most appropriate. This in most cases will be BeginInvoke.

Beware BeginInvoke

Updated 21/01: Included additional solution in download. See this entry.

After reading Matthew's blog entry in detail I have a few comments...

The code for this is available for download.

Is this really thread safe?

To answer this we must ask, what is the intended semantics? While there is little to go on, I have assumed that each click of the button should add the text, "plus a bit" to the end of the label. So clicking this button multiple times should result in that number of "plus a bit"s being added to the label.

Does this occur? What does the 'evil little daemon' have to say about this?

Download the code and give it a try... Click the button quickly 10 times, and watch the result.

It works... But is it safe?

The problem is that the evil little daemon is a slacker! He (or she) does not want to work all the time. So lets give him a hand.

Try inserting the line "System.Threading.Thread.Sleep(1000);" after the lock.

This puts the current thread (i.e. the worker) to sleep for 1000 milliseconds, giving the evil little daemon a chance to work his magic.

Run it again and see the results, clicking the button 10 times. In my case three "plus a bit"s were added to the label, with a little delay due to the sleep. Why? Race conditions, as I discussed earlier.

To view the problem for yourself, download the new version of the code and run it in the debugger. You can then view the changes that occur on the instance variable in the output window. You should notice that the value gets updated the correct number of times, but that the values are wrong (much like the account problem I discussed earlier).

Where is the problem? The problem exists because of the locking strategy. In this case the lock is acquired to read the value, but is then released allowing other threads to read and write to this value. This thread plans on reading the value, changing the value, and writing the value back (via the GUI thread). Because the lock is released after reading, it is possible that it has changed before the write occurs. As the semantics of our program require that none of these values get lost, this is not safe. So what can be done?

There are several potential approaches, so lets discuss them.

Solution 1
If the update can be performed on the worker thread then the update is simple. Move the updating of the value into the lock with the read. Now that is code is updating the instance variable we do not need to tell the GUI of the value of the string, the GUI can re-query for it. As a result we can use a standard method invoker and get the form to update itself.

The new code looks like this (I have changed "plus a bit" to " 1" as it is easier to count the correct number in the output)

lock( littleLockObject )
{
//read and update the string...
myUsefulString += " 1";
}

To make the test fairer this can be changed to:

lock( littleLockObject )
{
string copy;
copy = myUsefulString;
System.Threading.Thread.Sleep(1000);
myUsefulString = copy + " 1";
}

This way the sleep is between the read and the write, as it was before.

With this we can now consider the String to be our model and GUI our view. The GUI code only views the value, it doesn't update it. Ideally we could move this into another class, and then raise an even upon change etc...

When you run this you will see that all of the clicks get through to the label.

Solution 2
A much more complex solution is to remain with the updating of the instance variable from the GUI thread. In order to ensure that this works safely we must ensure that only one thread can be performing this operation at a time. We can do this by introducing a boolean variable that controls access to this functionality. The body of the method can then be guarded via a condition on this variable, see the code below:

public class Form1 : System.Windows.Forms.Form
{
private bool _MutexAvailable = true;

private void DoSomeWork()
{
string copy;
lock( littleLockObject )
{
while(false == _MutexAvailable)
Monitor.Wait( littleLockObject );

_MutexAvailable = false;
copy = myUsefulString;
}



So how does this work? The thread waits until _MutexAvailable is true, it then sets _MutexAvailable to be false and then processes the body of the method. No others can continue as they are blocked by the guard, i.e. they are waiting for _MutexAvailable to become true.

At the end of the method we now need to reset _MutexAvailable and wake any waiting threads. This must be done in a critical section to ensure safety. So the following code is added to the end of the method:

lock( littleLockObject )
{
_MutexAvailable = true;
Monitor.PulseAll( littleLockObject );
}

The PulseAll wakes the threads from the Wait at the top of the method.

Run the program again. Leave in the Sleep so that we are testing the same thing. Now all of the clicks result in an update of the label.

Is this safe? I am afraid that it is not...

Why?
Try adding a sleep to the UpdateTheUI method.

Running the program now causes incorrect updating again. The problem is now the use of BeginInvoke. With BeginInvoke a new thread is being used to update the value. This allows the worker to pulse another thread and have it read a stale value from the instance variable. The solution is to replace BeginInvoke with Invoke. It is critical that we wait at this point until after the instance variable is updated.

Running this again, with the two sleeps, and now it works correctly.

Solution 3
The problem with solution 2 is that it is full of thread management code that is not fun to play with (for most people). This can be extracted out into a utility class and can then be reused again and again. In this case the utility is called a Mutex. However, this is not the Mutex that comes with .NET, rather it is a lightweight Mutex.

The code now looks like this:

private void DoSomeWork()
{
string copy;

_MyMutex.Acquire();

try
{
//no need for lock, this is a reference to a immutable object
copy = myUsefulString;

System.Threading.Thread.Sleep(1000);

if( this.InvokeRequired )
{
Invoke( new StringMethodInvoker( UpdateTheUI ), new object[] { copy + " 1" } );
}
else
{
UpdateTheUI( copy + " plus a bit" );
}
}
finally
{
_MyMutex.Release();
}
}

The lock is no longer used as the Mutex provides us with the concurrency control.

Conclusion
Concurrency is difficult. There are no magic solution. BeginInvoke is a great tool, but you must take care if you want to ensure total safety.

Having said this, I cannot imagine the circumstances that would be required for this safety issue to raise itself without the inserted Sleep statements. Personally, however, I think you are best to try to make your application as safe as possible (i.e. live + safe).

Interacting with a GUI

If you look at GUI libraries in the .NET and Java platforms, you will find that these both require that interactions with the GUI are performed upon a single thread. This has become a hot topic lately, see Matthew Adams blog, and the related links.

So why is this implemented in this way?

This is a form of exclusion, enforced only by documentation (and the fact that you risk deadlocks if you ignore this).

Exclusion?
In a concurrent program multiple threads may attempt to access data elements at the same time. This can lead to a number of issues, referred to as race conditions. For example.

Consider the following pseudocode:

Thread 1:

1. Read account value
2. Increase value by $100
3. Write back new account value

Thread 2:

1. Read account value
2. Increase value by $50
3. Write back new account value

In a sequential (single threaded) programs there would be no issues with this type of code... However, if these two threads run concurrently then we have an issue.

Why?

The execution may occur in such as way that the result, after completion, does not result in the balance of the account increasing by $150. Imagine the following execution:

1. Thread 1: Reads the account value as $1000 (the starting balance)
2. Thread 1: Adds $100 to this, the result being $1100 is currently stored in a temporary variable.
3. Thread 2: Reads the account value as $1000 ($1100 has not been stored yet!)
4. Thread 2: Adds $50 to this, the result being stored in a temporary variable.
5. Thread 2: Writes the value back into the account, the accounts balance is now $1050
6. Thread 1: Writes the value stored in its temporary variable back into the account. The accounts balance is now $1100!

There are several ways to get around this issue, one such approach is called exclusion. Using this approach, you ensure that only one thread at a time can manipulate the shared data. Exclusion can be implemented via critical section, locks that allow only a single thread to enter the critical section of code. With the GUIs, the exclusion is by protocol. In essence, the documentation indicates that, while they don't stop it, you are not allowed to access these items from other threads.

The issue then is, so how do you interact with the GUI? The answer is, with care and invoke. I will leave the details for you to read in the linked articles above.

Concurrency

Yesterday I was sent an interesting article on concurrency. I have had a quick skim read of it and it is basically echoing what I have been saying over the last few months... Concurrency is the next big step in computing. Why? Multi-core CPUs.

In order to take advantage of multi-core CPUs, applications will need to be developed that use multiple threads. Multiple threads = concurrency. Concurrency = "You need to know what you are doing!" (have a read of some of the links from my site to concurrency issues such as Double Check Locking).

Having read this, it leads me to thinking, can you introduce concurrency into applications? I would agree to some degree that you can... You can offload things like loading images, saving and loading files, and background tasks., but generally the core functionality is usually single threaded. Will the offloading of "background" tasks give sufficient performance advantages, given the addition of concurrency control mechanisms? This is something that I need to do some more thinking on and will post my thoughts...

Let us consider an application example: PowerPoint: what threads could exist in this application?

1. Load and render slides (potentially many threads, using structural exclusion to load different slides)
2. User interface management (the GUI thread, interacted with from the threads above)
3. Save thread (save files... requires lock on model...)
4. Spelling and Gramma thread (interacts with changing model, and UI)

So multiple threads is possible, but this has greatly increased the complexity of the application. The model now requires appropriate critical sections, and/or locking strategies. How would this work in a team environment? Communication is the key. More developers need to know and understand concurrency, and strategies to overcome concurrency issues.

Beware Shameless Plug Below
So this bring me to the question:
Why do Advanced .NET at Swinburne?

Until recently Advanced .NET has been a subject that covered topics that most people would never work on again in their lives. This subject is hard. Most people work really really hard, and still only get a passing mark... What is the deal?

Advanced.NET deals with concurrency. This subject will help you learn about developing safe and effective concurrent applications.

Welcome Message

Welcome to my new BLOG.

My previous blog on the byte club server will no longer be active... Please ensure that you use my new feed to keep up to date.

If you are interested in finding older entries please refer to my old blog.

This blog will discuss my thoughts on software development, teaching, and other (sometimes related) work.