Re: Synchronization Vs Concurrency
From: John Morrison (john.morrison_at_tesco.net)
Date: 12/19/04
- Next message: Roy Battell: "Re: long long type"
- Previous message: Artie Gold: "Re: long long type"
- Next in thread: Giancarlo Niccolai: "Re: Synchronization Vs Concurrency"
- Reply: Giancarlo Niccolai: "Re: Synchronization Vs Concurrency"
- Reply: Jim Rogers: "Re: Synchronization Vs Concurrency"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 19 Dec 2004 04:34:40 -0000
Jim Rogers wrote:
> "Zahid Faizal" <zahidfaizal@canada.com> wrote in
> news:1100639531.519829.256120@c13g2000cwb.googlegroups.com:
>
>> I have often heard about synchronization and concurrency being talked
>> in tandem. I kinda know what this is all about ----- semaphores,
>> controlled access to critical resources blah blah blah. However, I
>> am not sure of the delineation between the two. What is the
>> "synchronization" part in this, and what is the "concurrency" part?
>> Can the two be talked about in isolation, or do they always exist in
>> tandem?
>>
>> Any insight will be appreciated.
>
> (I have trimmed the massive cross postings)
>
> Synchronization is one tool used in concurrent programs to ensure
> data integrity for data shared by several concurrent tasks.
>
> Concurrent programs can be written without any form of
> synchronization. In that case, either the concurrent tasks share
> no data, or any data corruption due to unsynchronized sharing
> is either impossible or unimportant.
>
> Concurrency deals with the creation, scheduling, and lifetime
> of concurrent tasks. Synchronization deals with the protected
> sharing of data and state information between concurrent tasks.
>
> A single-threaded program is completely synchronous.
> The purpose behind multi-threaded applications is to achieve
> greater asynchronous behavior, allowing many things to be
> done at the same time. Many multi-threaded programs still need
> some degree of synchronization to facilitate reliable communcation
> between concurrent tasks.
>
> Asynchronous communication often takes the form of signals.
> All the operating systems I am familiar with provide some set of
> signals to indicate a desired change of state in the concurrent
> task receiving the signal. Other than the signal itself, no data
> is sent from one concurrent task to the other in the communication
> of a signal. This is the reason that signals are very limited in
> their applicability as a communication between concurrent tasks.
> Most operating systems only support signals at the process level,
> and not at the thread level. Linux is an exception because of the
> strong similarity between threads and processes.
>
> Jim Rogers
The only other thing which needs emphasis here is real *vs* apparent
concurrency. The former is available (indeed, inevitable!) on systems with
more than one processor, and needs some "tricks" (/e.g./ spin locks) at the
system level for guarding OS resources against simultaneous access by OS
code on different processors. With one processor only, all concurrency is
apparent, since one processor can - obviously! - do only one thing at a
time.
At the process/thread level, there should be no difference: even if two
(or more) threads of the same process are running simultaneously on
different processors, the OS's mutual exclusion provisions - whatever names
they have on the OS you are using - are used in exactly the same way as on a
single processor system.
John
johnDOTmorrisonATtescoDOTnet
-- "Beware of bugs in the above code; I have only proved it correct, not tried it." - Donald Knuth
- Next message: Roy Battell: "Re: long long type"
- Previous message: Artie Gold: "Re: long long type"
- Next in thread: Giancarlo Niccolai: "Re: Synchronization Vs Concurrency"
- Reply: Giancarlo Niccolai: "Re: Synchronization Vs Concurrency"
- Reply: Jim Rogers: "Re: Synchronization Vs Concurrency"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|