2 Replies - 1355 Views - Last Post: 02 October 2012 - 04:46 PM

#1 heenan0420  Icon User is offline

  • D.I.C Head

Reputation: 0
  • View blog
  • Posts: 64
  • Joined: 07-October 11

Concurrent Programming and Race Conditions

Posted 02 October 2012 - 08:11 AM

So I had a general question about race conditions in concurrent programming. I am not working on a program right now I am just a little confused on how these two relate to one another. I know what they are separately I just don't know how they work together or what would happen in cases of errors. Any explanation would be great Thanks in advance.
Is This A Good Question/Topic? 0
  • +

Replies To: Concurrent Programming and Race Conditions

#2 xclite  Icon User is offline

  • I wrote you an code
  • member icon

Reputation: 1266
  • View blog
  • Posts: 4,064
  • Joined: 12-May 09

Re: Concurrent Programming and Race Conditions

Posted 02 October 2012 - 03:21 PM

Uh. Race conditions don't happen without some kind of concurrent execution, so I'm kind of curious how you know what they are separately.

How would you define a race condition?
Was This Post Helpful? 1
  • +
  • -

#3 Lemur  Icon User is offline

  • Pragmatism over Dogma
  • member icon

Reputation: 1439
  • View blog
  • Posts: 3,609
  • Joined: 28-November 09

Re: Concurrent Programming and Race Conditions

Posted 02 October 2012 - 04:46 PM

Rather simplified definitions, but...

Race Condition - Multiple processes trying to access the same mutable data, causing potential blitzing of the information, output, or otherwise.

Concurrent Programming - Multiple things executing at the same time, such as threads or separate programs.


Here's the fun part, attempting to get concurrent processes on a distributed environment with multiple sources of mutable data.

You're looking into Semaphores, Mutex, Message Passing, and Monitoring. Read up on those and it will make more sense.

Some classic problems to look into:

> The Dining Philosophers
> Producers and Consumers
> The Smokers

There are quite a few ways to go about this one, and this is actually what I'm writing a fairly lengthy paper on for my OS class. I chose to go about it a different way. I chose to go with a far more functional paradigm.

While elimination of mutable data is danged near impossible, you can do a lot to add immutability and functional purity to tasks to ensure that you mitigate the risk of collisions and botched data as much as possible.

Functional purity is the concept that if you put the same thing in a black box, you always get the same resultant out. This means that there can be no modification of the sender.

It's an interesting subject to look into, but trippy for those of us straight off the boat from OO land.
Was This Post Helpful? 1
  • +
  • -

Page 1 of 1