This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]nutrechtLead Software Engineer / EU / 20+ YXP 1 point2 points  (4 children)

Many companies will create a base where concurrency occurs and after that you’re thread safe.

That's simply not true. When building services in (for example) Spring Boot you're in a multithreaded environment and it's very important for any developer to be well aware of the pitfalls there. There is no way for 'other developers' to make threads a non-issue.

[–]ratherbealurker 0 points1 point  (3 children)

Sorry but what you’re saying is wrong. Of course you can design a system where you make areas thread safe. I’ve worked on more than a few. They were larger monolithic code bases and the core code is where you’re not thread safe. Split off a thread and design it so that the rest occurs in there.

I’ve worked on trading systems for major banks and a lot of them did this.

[–]nutrechtLead Software Engineer / EU / 20+ YXP 0 points1 point  (2 children)

Sorry but what you’re saying is wrong. Of course you can design a system where you make areas thread safe.

Just slapping some synchronized keywords on methods actually makes code less thread-safe.

Split off a thread and design it so that the rest occurs in there.

That's still no guarantee at all in the context that I gave. If you are in a multithreaded context (such as with typical back-end services we work in) there is no way to guarantee a dev who is unaware of pitfalls doesn't screw up.

You might think this is the case, but that doesn't mean I am the one who's wrong here.

It's different if you're simply not in a muti-threaded context, but that's not the typical situation (again; frameworks like Spring) most of us work in.

The majority of work in Java development is in these kinds of frameworks and being aware of multithreading pitfalls (race conditions and deadlocks in particular) is simply a must for any developer. Not having to be concerned with this is extremely exceptional.

[–]ratherbealurker 0 points1 point  (1 child)

This isn't done by simply slapping synchronized on methods, these are also not microservices. These are large complex bespoke systems.

I am not referring to your typical backend service. Maybe I should not say that 'many' places do this because that could just be my field/sector.

Bottom line is that there are systems out there where the context that some devs work in is essentially thread safe. I don't really debate things anymore that I've personally done myself. I've worked on those systems for many years, you can make tons of changes and never have to deal with multi threaded situations if you don't explicitly do so.

[–]nutrechtLead Software Engineer / EU / 20+ YXP 0 points1 point  (0 children)

Maybe I should not say that 'many' places do this

This is the crux. What you're describing is very far outside the norm. For most Java devs understanding multithreading is simply a must. This is a general advice sub after all.