Sure, you can do anything in any Turing-complete language. But it really helps if the language naturally provides the semantics for what you're trying to express.
Some people think of OOP as "inheritance and polymorphism", but that's really a corner case, but the heart of it is clear expression of "here's the minimal bit of code that needs to know the implementation details of this stuff".
Why are you needing to take multiple locks? Why can't that be done in a way that lock ordering isn't entirely trivial? Usually the answer is that the code is overcomplicated before even considering the multi-threaded aspect of it. Poor division of responsibility, too much global state, using SQL like it was the 20th century, that sort of thing.
No, negative 0 is NOT less than 0. It is in fact equal to 0 - unless you do a special total-order comparison.
In Java, it is. So there's a bug.
Dividing by 0 will either give INF or NaN. They will never compare as equal.
In both Java and C#, they compare as.equal(), but not as ==. So there's a couple more bugs. Especially in Java, where you end up using Double instead of double a lot, because generics are broken, and it's best to avoid == with any of the boxed numeric types, because, well, Java.
Only in the sense that you can use C to write an OOP language. I guess that's why they say "any sufficiently complex C program re-invents C++, poorly".
single-responsibility taken to the extreme. I don't like more than one piece of code modifying shared state
Yes, what could OOP possibly have to do with that kind of programming? It's a mystery. Totally unrelated: if only there were some approach to taking some state, and the only bits of code that should modify that state, and grouping them together in some sort of self-contained object. Nah, pipe dream.
You're humor detector needs its annual checkup - probably a deadlock somewhere. It's "an illustration of a basic issue in computer science" that never seems to come up. Academia is full of those.
Meanwhile, in the real world, pick the right architecture and you can avoid being overly clever.
I haven't played with.NET asynch yet - but what you say is about what I expected. I did only asynch operations in my first 5 years for coding, as there were no threads (those who know, know excp and wait). It scaled quite nice back in the day: 2000 active users on a (single core) machine with 200 MHz. Scaled to a modern high-end server, that would be a million active users on that box. But no one cares about (that kind of) performance any more.
Though I have to ask - how would you cram 100Gb of networking into one box? There's no PCI slot that can keep up with 2 x 10 Gb, and a 10-slot 16x PCIe server board is exotic, to say the least. People don't care about performance, because it's easier to just spin up more machines in the cloud.
If you try and get more detail, you're chided for not working quickly enough, or for bothering them.
Well, you'll never get very far if your boss is entirely unprofessional, to be sure. But "not working quickly enough"? Sounds like there isn't a schedule. "Bothering them?" doesn't take much time to answer a few questions - most people are happy to explain what they want, feels like leadership.
My policy is always to give such people what they ask for.
While passive-aggressive bullshit is a common approach among programmers, it's still a bad approach.
Hmm, perhaps we're using different terms. In modern Intel architecture, the INC instruction isn't guaranteed to be atomic unless you decorate it with some other instructions, so, sure, x++ can end up not being threadsafe. I wouldn't call it an atomic operation.
OTOH, use lock exch instead and you get the guaranteed-atomic behavior. That's why you lean on the "atomic" stuff in your platform library, such as InterlockedIncrement or AtomicInteger, and leave it to the compiler writers to do the platform-specific instructions to get the guarantee you need.
Ah, you must work in a different problem domain than I do. I've never had to care about display dates except to, well, display them. I need things to time out after the correct number of milliseconds, even if DST happens, or it's a leap day, or the user changes the time zone.
Do you work with something horrible like GUIs or accounting? My sympathy.
Atomics are cache-piercing, or they're pretend-atomics, which is about what that doc says. That's why they're particularly slow on a multi-socket system. The coder doesn't need to understand how it works, other than it's slow. The coder does need to understand that the compiler optimizer might not guarantee ordering around atomics, however, though it's rarely an issue.
The problem is, people will write if (x * 3 < 1)... then be mystified when it fails. My favorite is all the if (x < 0)... bugs, failing to realize that negative zero is less than zero. Great fun.
Then there are the NaN-related bugs, which are the sort of math errors most people overlook - like dividing X and Y by N, which accidentally is 0, then later comparing them and discovering that they're equal.
The problem is, people will write if (x * 3 then be mystified when it fails. My favorite is all the if (x bugs, failing to realize that negative zero is less than zero. Great fun.
Then there are the NaN-related bugs, which are the sort of math errors most people overlook - like dividing X and Y by N, which accidentally is 0, then later comparing them and discovering that they're equal.
Boss: this isn't what I wanted, did you read the spec? Me: you gave me a ticket that had 3 sentences in it. That's not a spec. Boss: that is too a spec. Go back and read it. Me: this leaves a ton open to interpretation. This isn't a spec. You need to clarify this with a lot more detail. Boss: come on, you knew what I meant.
And that's partially why I quit.
So you didn't ask your boss what he actually wanted before you started coding? You didn't ask for clarification for each ambiguity you discovered during coding? You just shat something out at random?
Well written threaded code is well factored with single-responsibility taken to the extreme. I don't like more than one piece of code modifying shared state.
OOP really shines for this sort of thing. It's one reason concurrency is a pain in C in particular.
The media was not running in this election, but anyway
Most newspapers, TV news, and cable news other than Fox is just the DNC, entertainment division. When 95% of reports donate to Hillary, then, yeah, they certainly lost the election.
However imperfect the media may be sometimes, it's vital to have it around if democracy is to function.
Nope. A source of news is vital, but centrally controlled broadcast propaganda? Its time has passed.
If was never hard to ifdef around Windows and Linux threads. Back when you also had to care about all the Unix platforms (some of them fairly primitive) that was a pain.
For microseconds, a long works fine too (just make sure your names include the units). For nanoseconds, it's a pain, but how often does sub-microsecond resolution really come up?
Slashdot Mirror
Sure, you can do anything in any Turing-complete language. But it really helps if the language naturally provides the semantics for what you're trying to express.
Some people think of OOP as "inheritance and polymorphism", but that's really a corner case, but the heart of it is clear expression of "here's the minimal bit of code that needs to know the implementation details of this stuff".
Or, c) pick a design that actually works.
Why are you needing to take multiple locks? Why can't that be done in a way that lock ordering isn't entirely trivial? Usually the answer is that the code is overcomplicated before even considering the multi-threaded aspect of it. Poor division of responsibility, too much global state, using SQL like it was the 20th century, that sort of thing.
Ah, by "special total-order comparison" did you mean compareTo()? In which case, fine, but that's what most Java library code seems to use.
No, negative 0 is NOT less than 0. It is in fact equal to 0 - unless you do a special total-order comparison.
In Java, it is. So there's a bug.
Dividing by 0 will either give INF or NaN. They will never compare as equal.
In both Java and C#, they compare as .equal(), but not as ==. So there's a couple more bugs. Especially in Java, where you end up using Double instead of double a lot, because generics are broken, and it's best to avoid == with any of the boxed numeric types, because, well, Java.
It sounds like you never got the hang of it, TBH.
Only in the sense that you can use C to write an OOP language. I guess that's why they say "any sufficiently complex C program re-invents C++, poorly".
single-responsibility taken to the extreme. I don't like more than one piece of code modifying shared state
Yes, what could OOP possibly have to do with that kind of programming? It's a mystery. Totally unrelated: if only there were some approach to taking some state, and the only bits of code that should modify that state, and grouping them together in some sort of self-contained object. Nah, pipe dream.
You're humor detector needs its annual checkup - probably a deadlock somewhere. It's "an illustration of a basic issue in computer science" that never seems to come up. Academia is full of those.
Meanwhile, in the real world, pick the right architecture and you can avoid being overly clever.
I haven't played with .NET asynch yet - but what you say is about what I expected. I did only asynch operations in my first 5 years for coding, as there were no threads (those who know, know excp and wait). It scaled quite nice back in the day: 2000 active users on a (single core) machine with 200 MHz. Scaled to a modern high-end server, that would be a million active users on that box. But no one cares about (that kind of) performance any more.
Though I have to ask - how would you cram 100Gb of networking into one box? There's no PCI slot that can keep up with 2 x 10 Gb, and a 10-slot 16x PCIe server board is exotic, to say the least. People don't care about performance, because it's easier to just spin up more machines in the cloud.
Do children get to sue over the accumulating National Debt they will be saddled with.
Sure, they might even win, and the government could pay them $X, by means of increasing the national debt by $X. Everyone wins!
but one of the Clintons was never indicted.
One of the Clintons hasn't yet been indicted. Plenty of time next year.
If you try and get more detail, you're chided for not working quickly enough, or for bothering them.
Well, you'll never get very far if your boss is entirely unprofessional, to be sure. But "not working quickly enough"? Sounds like there isn't a schedule. "Bothering them?" doesn't take much time to answer a few questions - most people are happy to explain what they want, feels like leadership.
My policy is always to give such people what they ask for.
While passive-aggressive bullshit is a common approach among programmers, it's still a bad approach.
I think a better way of saying this is: "Atomic operations do not magically fix race conditions. Locks are almost always what you want."
Hmm, perhaps we're using different terms. In modern Intel architecture, the INC instruction isn't guaranteed to be atomic unless you decorate it with some other instructions, so, sure, x++ can end up not being threadsafe. I wouldn't call it an atomic operation.
OTOH, use lock exch instead and you get the guaranteed-atomic behavior. That's why you lean on the "atomic" stuff in your platform library, such as InterlockedIncrement or AtomicInteger, and leave it to the compiler writers to do the platform-specific instructions to get the guarantee you need.
Ah, you must work in a different problem domain than I do. I've never had to care about display dates except to, well, display them. I need things to time out after the correct number of milliseconds, even if DST happens, or it's a leap day, or the user changes the time zone.
Do you work with something horrible like GUIs or accounting? My sympathy.
Atomics are cache-piercing, or they're pretend-atomics, which is about what that doc says. That's why they're particularly slow on a multi-socket system. The coder doesn't need to understand how it works, other than it's slow. The coder does need to understand that the compiler optimizer might not guarantee ordering around atomics, however, though it's rarely an issue.
I have 1.99999999999 problems but a bitch aint one?
I have 98.9999999997 problems, but an int ain't one.
Freaking slashcode:
The problem is, people will write if (x * 3 < 1) ... then be mystified when it fails. My favorite is all the if (x < 0) ... bugs, failing to realize that negative zero is less than zero. Great fun.
Then there are the NaN-related bugs, which are the sort of math errors most people overlook - like dividing X and Y by N, which accidentally is 0, then later comparing them and discovering that they're equal.
The problem is, people will write if (x * 3 then be mystified when it fails. My favorite is all the if (x bugs, failing to realize that negative zero is less than zero. Great fun.
Then there are the NaN-related bugs, which are the sort of math errors most people overlook - like dividing X and Y by N, which accidentally is 0, then later comparing them and discovering that they're equal.
Reminds me of my last job.
Boss: this isn't what I wanted, did you read the spec?
Me: you gave me a ticket that had 3 sentences in it. That's not a spec.
Boss: that is too a spec. Go back and read it.
Me: this leaves a ton open to interpretation. This isn't a spec. You need to clarify this with a lot more detail.
Boss: come on, you knew what I meant.
And that's partially why I quit.
So you didn't ask your boss what he actually wanted before you started coding? You didn't ask for clarification for each ambiguity you discovered during coding? You just shat something out at random?
Well written threaded code is well factored with single-responsibility taken to the extreme. I don't like more than one piece of code modifying shared state.
OOP really shines for this sort of thing. It's one reason concurrency is a pain in C in particular.
The media was not running in this election, but anyway
Most newspapers, TV news, and cable news other than Fox is just the DNC, entertainment division. When 95% of reports donate to Hillary, then, yeah, they certainly lost the election.
However imperfect the media may be sometimes, it's vital to have it around if democracy is to function.
Nope. A source of news is vital, but centrally controlled broadcast propaganda? Its time has passed.
As it happens, I never been asked to solve philosophical problems. Real-world problems tend to be rather more boring.
If was never hard to ifdef around Windows and Linux threads. Back when you also had to care about all the Unix platforms (some of them fairly primitive) that was a pain.
For microseconds, a long works fine too (just make sure your names include the units). For nanoseconds, it's a pain, but how often does sub-microsecond resolution really come up?