Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Detecting Deadlocks in C++ Using a Locks Monitor

By Tomer Abramson, April 01, 2003

Post a Comment

In multithreaded programming, locking mechanisms are a must in order to keep data consistent. This article will discuss a technique for detecting and breaking deadlocks in multithreaded environment. It will also present a simple and powerful way to analyze why the deadlock occurred.
Detecting Deadlocks in C++ Using a Locks Monitor

Listing 4 Output file lockMonitor log

*** Detect deadlock. Dump stack of all threads in deadlock cycle ***

start stack trace for thread 1732:

address 2012751848
function: NtWaitForSingleObject
module: ntdll.dll

address 2011708251
function: ExitVDM
module: KERNEL32.dll

address 4241383
function: void __cdecl f1(void)
file: d:\locksmonitor\main.cpp
line: 20 + 14 bytes
module: LocksMonitor.exe

address 4241501
function: unsigned long __stdcall Thread_1(void *)
file: d:\locksmonitor\main.cpp
line: 29 + 0 bytes
module: LocksMonitor.exe

address 2011784483
function: SetThreadAffinityMask
module: KERNEL32.dll
finish stack trace for thread 1732:
start stack trace for thread 2032:

address 2012751848
function: NtWaitForSingleObject
module: ntdll.dll

address 2011708251
function: ExitVDM
module: KERNEL32.dll

address 4241223
function: void __cdecl f2(void)
file: d:\locksmonitor\main.cpp
line: 11 + 14 bytes
module: LocksMonitor.exe

address 4241565
function: unsigned long __stdcall Thread_2(void *)
file: d:\locksmonitor\main.cpp
line: 35 + 0 bytes
module: LocksMonitor.exe

address 2011784483
function: SetThreadAffinityMask
module: KERNEL32.dll
finish stack trace for thread 2032:
killed thread 1732 In Order to break deadlock



Previous 3 4 5 6 7 8 

Related Reading

News

Commentary

Slideshow

Video

Most Popular

More Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>
INFO-LINK


Avatar
MeritC602

You can clear many of your doubts regarding data types in Core Java through Merit Campus, visit: http://java.meritcampus.com..., http://java.meritcampus.com...

Not only data types, we also have each and every topic in Core Java with example for each. You can read lot of sessions and can write many practice tests in Merit Campus Java website. visit: http://java.meritcampus.com... to know more.

Avatar
AjoyB

Eric,

Even if this is a Java specific blog, I think it should be mentioned that this behavior is due to the way IEEE 754 Floating Point Arithmetic standard works, and that it is not specific to Java. I do not like the statement that "...shortcuts are taken with float and double" (by Java). Even int and long have a finite number of bits and so cannot represent numbers larger than MAXINT or MAXLONG exactly. The difference is that with floating point numbers, the numbers that cannot be represented exactly are interspersed with those that can, so there is no fixed range within which they are always exact.

Avatar
eric_j_bruno

Thank you for that thorough explanation. I'll check out that paper. Thanks again.

Avatar
robinrosenberg

Floating point does give exact answers given the right conditions.

E.g. if you supply a value with five decimal digits before conversion to decimal, you should convert to a maximum of five digits when converting back to decimal.

Double gives you 16 decimal digits of precision. So if you convert a decimal number with 16 digit or less to FP and back you get the exact result. But you need to round to the number of significant digits you expect since FP does not keep track of that for you.

Then you may lose precision during operations, For multiplication and division, a rule of thumb is that you lose at most one digit per operation. For addition and subtraction it is more complicated, but think of it as aligning around the decimal point. If the maximum number of digit before and after the decimal point, including the result, overall is larger than 16 digit, you lose precision, otherwise you don't.

In your example you need eight digits, well withing the precision of double, so the result when converted back to decimal with the significant number of digits, is in fact exact. The error in the original code is that it outputs the results with excess precision.

IEEE floating point is exact, as long as you don't overstep the precision, which means you need to estimate the total error in your calculations regardless of whether you are counting pennies or forecasting the weather.

For money this is problematic because most calculations fit fine within the precision of double, but just barely and many accountants expect that even amounts of a thousand trillions are computed to the penny, because that's how debit and credit are balanced.

As for "can't use for money", I think that statement is invalid. Excel is the most widely used tool for monetary calculations and it uses floating point. Sure people make huge mistakes in their spreadsheets, but that's not due to the use of floating point. Trading systems also use floating point heavily, so apparently it works quite well.

C/C++ programmers on many platforms can use long double which has 35 or so decimal digits which allows for quite a lot of calculations before any significant loss of precision occurs.

Of course the safe way is to use BigDecimal and only BigDecimal. You mix double and BigDecimal which bad and is likely to get you into trouble someday. I've seen worse though. BigDecimal has a constructor from String, so you could write this instead that has no floating point at all.

BigDecimal a = new BigDecimal("106838.81");
BigDecimal b = new BigDecimal("263970.96");
BigDecimal c = new BigDecimal("879.35");
BigDecimal d = new BigDecimal("366790.80");

BigDecimal total = BigDecimal.ZERO;
total = total.add( a );
total = total.add( b);
total = total.subtract( c );
total = total.subtract( d );

There is a paper called "What Every Computer Scientist Should Know About Floating Point" that explains all the details of when you can expect exact results from floating point.

Avatar
dleppik554

I think it's not just that people don't know about BigDecimal (they probably pass it in JavaDoc many times), but that using BigDecimal means (1) your formulas become far more obtuse and hard to read, and (2) you can't use floating-point libraries and frameworks.

Leaving operator overloading out of Java was probably a good thing, but it makes it a bad language for finance. I'd say just use Scala, but then you'd have to spend two years learning Scala-- which is made harder because of... operator overloading.

Avatar
Deirdre Blake

Ha! You caught us tripping over our attempts to be clever in headline writing. In all fairness to Eric, that was my goof in editing the blog post. The correction has been made.

Avatar
tdisarlo190

"Inprecise" is more imprecise than floating-point! :)

Avatar
jjohnston209

I am more mystified by the title. I was looking for the 'hook' as to why floating point math is 'in-precise' as opposed to 'imprecise'. I guess it was just a typo. Please be more careful when using terms that are either incorrect or imprecise, as they are more misleading in the context in which they are used.

Avatar
Andrew Binstock

It is ridiculous, as you state. This problem has been known for years and, esp. in Java, there are classes specifically created to solve this problem (that is, the BigDecimal that Eric discusses). This is where, I believe, the self-taught history of some programmers comes back to bite them: they don't know what they don't know.

Avatar
tappa

I'm utterly depressed by the fact that twenty years after even I started working in banking I.T there still seem to be people who don't know that you can't use fp data types for financial calculations.
Please RTFM!
No matter what the language I'm sure it will say the same thing.

Avatar
eric_j_bruno

Thanks for the comment. I focused on Java since this is a Java specific blog, that's why I didn't say it was a flaw or bug. I didn't compare it to the behavior of other compilers and runtimes. Instead I focused on how to properly handle floating point math for financial calculations in Java using BigDecimal. I apologize if the title is misleading.

Avatar
tsikes

I'm mystified by this article. Not the observed behavior, but the explanation.

Here's the output from the same initial code using C++ (g++ on Linux Mint):

total: 3139.6200000000535510

That's the same result because it's calculated using IEEE 754 double precision floating point math - just as it is in Java. IEEE floating point math is well known to be unsuitable for financial calculations.

Please make it clear that this is in no way unique to Java, as even the title implies. It's simply a function of the normal behavior of IEEE floating point.

Recent Articles

Most Popular

Stories Blogs

Upcoming Events



Most Recent Premium Content

Digital Issues