At the beginning of this year I have posted a short questionnaire on concurrency on my blog. I have promised to publish the results, so here they are. The number of respondents was 27 (and not everybody answered all the questions).
Q: What is your role in application development?
Q: How many cores has your primary working station (PC, laptop)?
Q: What type of application(s) are you developing?
A: Windows and web applications, ERP, banking, internal, back-end, integrations (addins: IE, Outlook, etc.), VxWorks kernel-base applications under PPC603, Point-of-Sale, internal, Web site + ERP backend + e-commerce, web applications, Windows applications, Mac applications, control software, visualizations, scada, Linux embedded application, Windows forms, Windows .Net with WPF/WCF and Silverlight, integration technology platforms for CRM and ERP, Kernel mode drivers, filesystem drivers, graphic engines, CAD.
Q: What programming languages are used for your application development?
Q: One a scale from 1 to 5 how do you rate your level of awareness on concurrency issues?
Q: On a scale from 1 to 5 how do you rate your activity in getting informed and acquiring competence on concurrency (trends, tools, etc.)?
Q: What do you expect to happen to developers that won’t learn to program concurrently?
Q: On a scale from 1 to 5, how would you grade the level of parallization of your application?
Q: Does your application performance scale proportionally with the number of cores?
Q: What libraries and tools are used in your application for concurrency?
A: System.Threading, The built-in threading classes, OS support (CRT, Win32 API), VS2010, .Net Framework – Thread, ThreadPool, Task, Monitor, lock() and many own written libraries (synchronized objects, asynchron calls and functions), MFC framework, .NET framework, Qt framework, Java framework, My own using RAII, nothing special: self made priority queues and thread pools, Win32 API’s, Windows threads.
Q: Give examples of routines in your application that are executed in worker threads.
A: loading of grids which care displayed at startup in the main application window, logging, tracing, loading data (in some cases), long running tasks (computations, report generation also in some cases), HTTP lenghtly posts, Outlook inbox scan for text, a job/task manager for things that are triggered by web UI but are not required to output any result to the client, data processing, database interactions, database data loading/uploading, looped data acquisition presented in chart monitors, sattelite data scaning and sectioned for DVB-S systems, any operations where I need to start/stop, all long running operations, application request processing, connection management, I/O, Open large files, communication, file uploads, update checking.
Q: Give examples of routines in your application that execute in the main (UI) thread and can be refactored to execute in worker threads.
A: loading all application modules, SQL queries, draw rows of panels – maybe even threading each individual block per row, all data processing which take more than a few seconds and which are not dependent or influence other events on UI, I’ve been multi-threaded programming for so long, I usually design the app for multi-theading up front, long (minutes) calculations, user triggered opening of multiple files, opening of a single file, certain post-processing of data, database stuff.
Q: Give examples of routines in your application that are parallelized.
A: logging and Tracing with multiple outputs (File System, Debug Window, Activity Logs written to database), UI, background processes, sending emails, invokes an event multithreaded in an own ThreadPool, all data processing in an application running in a sattelite set top box, zapit-thread, epg-thread, timer thread, other threads controlling whichever driver involved: front panel display driver, sound driver etc., remote connection handling, data processing, 3d transformations.
Q: Give examples of routines in your application that could be parallelized to improve performance.
A: cost computation and distribution for productions chains, the rest, all timers routines should turn to threads, all routines that take more than a few seconds and locks the UI, send-request-and-wait-response logic (actually I was thinking of SEDA kind of processing), importing models from project files.