Category Concurrency Patterns

Click the title to see all topics in this category.

Concurrency-related patterns focus on the interactions between tasks that execute in parallel for SystemsSoftware.

• AvoidThreadsForOptimizations
• CoarseGrainLocking
• DisableJobRequestsWhileRunningJob
• DoubleCheckedLocking
• GuardedSuspension
• OrderedLocks
• ReadWriteLock
• SchedulerPattern
• SemaphoresForMutualExclusion
• SoftwareTransactionalMemory (does this belong here?)
• SynchronizationStrategies
• SynchronizedSmartPointers
• SynchronizedTightGroupOfClasses
• TrafficCop
• WriteYourOwnThreadingPackage

---

Is there a difference between a "Concurrency Pattern" vs. a "Synchronization Strategy"?

Yes, although it might be splitting hairs a bit. Synchronization implies interaction, whereas concurrency can mean anything from interaction to isolation. Synchronization is about working towards some common goal; Isolation is about avoiding interaction/interruption while working towards independant goals; Concurrency is doing things at the same time in general. It might be appropriate to refactor the pages along those lines, as there could be more written about the isolation end of things than there currently is. --WilliamUnderwood

(EditHint: if there's no difference, I'm going to delete page SynchronizationStrategies and move its text to page CategoryConcurrencyPatterns )

---

Someone added the following point above, which I have moved here:

"Use a database or database engine for large collection processing when possible. The database has a better chance of later scaling to multiple processors than hand-coded equivalents."

The intent of that suggestion may be appropriate to end-user application development, but it is poorly expressed. For example, a database cannot -- in and of itself -- be used for concurrent "large collection processing." A database is a collection of data. As such, it can only support concurrency if accessed strictly via a database management system, database engine, or other concurrency management mechanism. Therefore, one would not choose between "a database or database engine" for large collection processing in this context.

Please clarify. Usually one mixes/allocates processes between local applications and databases.

Sorry, I missed out the word "concurrent" in a sentence above. A database is data, not software. Data does not provide concurrency controls. Software, like a DBMS, provides concurrency controls.

However, it would appear that this page is intended to reference systems programming patterns -- for example, those used to construct the internals of (among other things) concurrent DBMSes. As such, it is inappropriate -- and not helpful -- to effectively recommend that a database engine should be used to implement a database engine.

Why is it limited to SystemsSoftware? If so, perhaps we need to look into a title change.

I don't think a title change is necessary. The scope of discourse is obvious from the content, except perhaps to those not familiar with systems programming.

I changed the wording of the intro to make it explicit. Note that concurrency is important to many domains, not just SystemsSoftware. And, they have patterns also (perhaps some of the same ones). Thus, I find the categorization + title confusing.

See also ParallelProgrammingDiscussion. It is likely that similar issues and therefore patterns will occur in application software which is running on more than one processor. -- JohnFletcher

---

CategoryConcurrency CategoryCategory