P. 1


|Views: 170|Likes:
Published by Arun Nair

More info:

Published by: Arun Nair on Jun 09, 2012
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





When providing locks for a shared component in a concurrent pro-
gram, either by hard-coding a particular lock type into the component
or by implementing STRATEGIZED LOCKING (388) . . .

. . . a key issue in multi-threaded programming is to ensure that locks
are acquired and released automatically when entering and leaving
critical sections.

A critical section of code that should run sequentially is often
protected by a lock, which is acquired and released whenever
control enters and leaves the critical section. If programmers
must acquire and release this lock explicitly, however, it can be
hard to ensure that all paths through the code release the lock.

Control can leave a scope early due to an uncaught exception, or an
explicit ‘exit statement’ such as return, break, or goto. The lock’s
release code may therefore be missed as a result of programmer
oversight. The more complex and verbose code becomes, the more
likely such oversights will occur. Code that tries to achieve exception-
safety through the explicit use of statements like try, catch, and
re-throw is error prone, losing both clarity and the intended safety.


Scope the critical section—if this has not already been done—
and acquire the lock automatically when control enters the
scope. Similarly, automate the release of the lock when control
leaves the scope via any exit path.

## Execute the critical section.

end## Leave the critical section.

## Release the lock automatically.

do_something ();

## Acquire the lock automatically.

begin## Enter the critical section.




Entering a critical section becomes thread-safe, and leaving the criti-
cal section safely releases all acquired locks.

Scoped Locking **


SCOPED LOCKING increases the robustness of concurrent software by
eliminating common programming errors related to synchronization
and multi-threading. In addition, locks are acquired and released
automatically when control enters and leaves critical sections, which
are defined by programming language method and block scopes.

The implementation of SCOPED LOCKING depends on the language used
to program concurrent software. For example, Java provides a lan-
to generate a corresponding block of bytecode instructions in which a
monitorenter and a monitorexit bracket the block. To ensure that
the lock is always released, the compiler also generates an exception
handler to catch all exceptions thrown in the synchronized block
[Eng99]. If the locking scope covers the whole method, the method
itself can be marked as synchronized. However, because marking
the method is slightly simpler to write than a synchronized block,
it is tempting to fall back on this briefer approach. Unfortunately, in
many cases this means that the lock scope becomes larger than the
critical section, leading to a loss of concurrency.

C++, by contrast, does not provide direct language support for SCOPED
LOCKING, but it can be implemented as a C++ idiom via an EXECUTE-
AROUND OBJECT (451). Use this idiom to create a guard class whose
constructor acquires a lock and whose destructor releases it. A guard
object is thus declared as a local variable within the critical section’s
scope and before its first statement. When control enters the critical
section, the guard’s constructor is called and acquires the lock.
When control leaves the critical section via any exit path, the guard’s
destructor is called automatically, due to C++ semantics, to release
the lock. Designing the guard object as a WRAPPER FACADE (459) helps
to encapsulate the details of a particular platform-specific locking
mechanism behind a uniform interface.



You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->