A Day in the Life

A day in my life. Thoughts on leadership, management, startups, technology, software, concurrent development, etc... Basically the stuff I think about from 10am to 6pm.


Concurrent Development: Pieces and parts...

I hope that you took my last post seriously. While kind of kooky the approach actually works and for those of you who are old enough to remember the shift to object oriented development; we need all the help we can get. Let’s say that you’ve taught yourself how to look at the world with the eyes an experienced multitasker. Now it’s time to start thinking about how to apply this new way of thinking to your code.

There are three main areas in concurrent program design: decomposition, communication, and synchronization.

Decomposition - the task of identifying both functions and data within an application that have parallelizable elements as well as identifying shared resources.

Communication - how the parallelizable elements communicate with each other and/or the rest of the application.

Synchronization - how to manage the creation, execution, and termination of the parallelizable elements such that shared resources are not corrupted or locked out and the expected results are achieved every time.

Start and end with decomposition because you will need to continuously exam your application for opportunities and potential problems. Any engineer using concurrency must approach software development as a big picture activity. Generally this has been the responsibility of the architects and leads, but now it’s yours as well. If you’re going to use concurrency in your applications you MUST understand how your application is put together. You must be able to identify:

1. Parallelizable areas that perform the same function over and over, but act on different data. You will often find these algorithms in loops.

2. Parallelizable areas that are not algorithmically connected and can execute at the same time. The obvious example of this is a UI thread and a background worker thread.

3. Critical areas of code that must never be executed in parallel. These codes sections are often found around shared resources that must be accessed sequentially.

4. Large bulk processes that can be easily split up and processed in parallel. An example of this is the breaking up of a large EDI (Electronic Data Interchange) file for ETL (extract, transform, and load).

Know your code. Know your tools. Know your business.



Post a Comment

Links to this post:

Create a Link

<< Home