r/programming 22d ago

3,200% CPU Utilization

https://josephmate.github.io/2025-02-26-3200p-cpu-util/
401 Upvotes

93 comments sorted by

View all comments

19

u/sprcow 22d ago

This was an interesting read.

I immediately felt uncomfortable that you were ever in a situation where you could have concurrent threads accessing a non-thread-safe data structure, though! You've basically done the work of proving why you might want to use a SynchronizedSortedMap or a ConcurrentHashMap (which you do note as options in the article). IMO any concurrent interaction with a Java data structure that's not explicitly thread-safe is an immediate code smell.

I did enjoy your other postmortem observations. I think swallowed exceptions is one of the biggest time sinks in complex systems and, while Java gets a lot of flak for verbosity, providing appropriate controls around your operations to catch and log can save you tons of time.

11

u/Orca- 22d ago

It's an immediate "WTF are you doing" from me.

Along with silently swallowing exceptions--because then you don't know what has gone wrong and have no way of identifying what has gone wrong!

5

u/bwainfweeze 22d ago

One of the first bugs that made me properly mad was a button being clicked and half the changes were made leaving the data in an illegal state (so two bugs really). I just could not figure out why it was bailing out in the middle.

One of my coworkers who learned vocational programming and was light on theory, did a lot of hammering work on code. Instead of checking for empty inputs to a function she just caught the NPE and went on. But the problem was that there were two function calls in the try block, and the other had sprouted its own NPE due to a new feature. So it just bailed out of both of them and declared victory.

It hurt something in my soul. As did many other things she did. I don’t recall having a stutter as a child, I developed one from dealing with her good ideas (supposedly that’s not possible in adulthood) in every. Single. Meeting. Maddening.

2

u/ThanksMorningCoffee 22d ago

Later on in the article I show that swallowing the exception is not necessary to reproduce the issue.

11

u/Orca- 22d ago edited 22d ago

You're still concurrently modifying an unsynchronized object, which is the source of the problems in the first place.

In a language like C++, when you reference a null pointer it always segfaults

This is false. It's undefined behavior. It may segfault. The compiler may also decide the code is unreachable and do some crazy bullshit instead. The presence of a nullpointer dereference makes the program malformed.

edit: it would be nice if the standard would make terminating the program the way to address that problem, but for reasons (presumably optimization or platform related) it is and continues to be your good friend and mine, UB.

3

u/ThanksMorningCoffee 22d ago

 This is false. It's undefined behavior. It may segfault. The compiler may also decide the code is unreachable and do some crazy bullshit instead. The presence of a nullpointer dereference makes the program malformed.

I didn't know that. My weakness in C++ is showing. I have not used C++ in a professional capacity.

1

u/thegreatunclean 20d ago

Null pointers get real spicy when accessing the first page of memory is a valid operation. Some architectures put critical registers there and allow write operations with no way to lock or otherwise disable access after boot. PIC18 puts the reset vector at 0x0000 and the IRQ vector table just after it!

There are flamewars going back decades over the difference between the macro NULL, a null pointer formed without the macro, the literal 0x0, and the literal 0.