4 ms·

If you're using a try-commit-retry pattern (i.e. transactional memory), and the code using that pattern can't actually be rolled back and retried, then the code

by jbri 15y ago

If you're using a try-commit-retry pattern (i.e. transactional memory), and the code using that pattern can't actually be rolled back and retried, then the code is wrong. It's just as wrong as if it were to dereference a null pointer or read invalid memory. I'm not familiar with existing transactional-memory systems - but I'd guess the issue there is due to them not actually supporting batching all the side effects into a single transaction, which seems to be something that would be very doable in hardware.

jerf 15y ago
"and the code using that pattern can't actually be rolled back and retried, then the code is wrong." Well, yes, sure, that's easy to say, but the problem there is when your base language has no way of detecting mutations that can't be rolled back, you can't help but write wrong code. You've been doing it since the day you picked up your first programming language, after all. And in theory, C arrays are perfectly safe because you will always pass around their lengths and check the length every time you so much as glance at the array, but in practice it's hopeless and the only practical solution for mere mortals is Don't do that. STM actually suffers from this even worse because if you actually want to take advantage of the composition promises (and if you aren't getting that why bother with STM in the first place), it only takes one bad case in one block of code, with no feedback to the programmer that an untracked effect has occurred at any point, to bring the whole thing down. One of the whole points is that you can write transactional code that calls other transactional code and it's all supposed to Just Work in a way lock-based code can't be composed together, so a single transaction may run all over the program just like a single function call can. I can't hardly get my coworkers to properly encode their HTML, and you expect me to teach them about managing effects in a language that doesn't even acknowledge they exist as a distinct category of things? You can solve this by adding a concept of "effect" to your language, as Haskell does... but once you do that, you no longer have the same language. Not even close. None of the old libraries will work, more semantics will have to be tweaked, the change will ripple everywhere in both semantics and probably syntax, new coding patterns will have to be learned (and worse, unlearned!)... unless someone's come up with a really big breakthrough that everybody up to this point has missed. It's not a hardware problem, it's a semantic problem.
- jbri 15y ago
  It seems like your complaint is "shitty programmers will still do it wrong". Does this "solve" the concurrency problem so that the most craptastic of copy-pasters can write high-performance concurrent code? Hell no. But it never pretended to in the first place, so that's pretty much irrelevant. It's like saying that doing graphics processing in dedicated hardware is bad because a lot of programmers are awful at coding 3D graphics. Even if you look at this just as a convenience for compiler writers, this would significantly improve the performance for anything that does do transactional memory properly.
  - pjscott 15y ago
    It's also a very useful primitive for people writing shared data structures, like concurrent hash tables or multiple-producer, multiple-consumer priority queues.
  - jerf 15y ago
    The problem with C arrays is not that shitty programmers get them wrong; the problem with C arrays is that only programming gods walking amongst men get them right. Managing effects in a language without any support for it, and decades of work put into making effects easier to implicitly apply without even having to think about it, is at least as hard. There's more to the programming difficulty scale than "shitty" and "competent" and it's not a good idea to count on any programming technique that can only be used by the gods amongst men... even if you are one! (Writing raw string-concatenation-based HTML output safely is another example. No, you can't do it correctly in a large code base without help. Even if you are that smart, you aren't that superhumanly diligent.)
- rbranson 15y ago
  I think you misunderstand STM. STM is used to group and apply a few micro-operations, within a single function, but not many or over multiple functions, certainly not over multiple modules. It is not really for rebounding from exceptions in the general sense, as transactions are used in an RDBMS. It's more to keep the system in a stable state, something locks are usually used for in multi-threaded programming. Just as locks are best applied as fine-grained as possible, so is STM.

by jbri 15y ago

jerf 15y ago

"and the code using that pattern can't actually be rolled back and retried, then the code is wrong." Well, yes, sure, that's easy to say, but the problem there is when your base language has no way of detecting mutations that can't be rolled back, you can't help but write wrong code. You've been doing it since the day you picked up your first programming language, after all. And in theory, C arrays are perfectly safe because you will always pass around their lengths and check the length every time you so much as glance at the array, but in practice it's hopeless and the only practical solution for mere mortals is Don't do that. STM actually suffers from this even worse because if you actually want to take advantage of the composition promises (and if you aren't getting that why bother with STM in the first place), it only takes one bad case in one block of code, with no feedback to the programmer that an untracked effect has occurred at any point, to bring the whole thing down. One of the whole points is that you can write transactional code that calls other transactional code and it's all supposed to Just Work in a way lock-based code can't be composed together, so a single transaction may run all over the program just like a single function call can. I can't hardly get my coworkers to properly encode their HTML, and you expect me to teach them about managing effects in a language that doesn't even acknowledge they exist as a distinct category of things? You can solve this by adding a concept of "effect" to your language, as Haskell does... but once you do that, you no longer have the same language. Not even close. None of the old libraries will work, more semantics will have to be tweaked, the change will ripple everywhere in both semantics and probably syntax, new coding patterns will have to be learned (and worse, unlearned!)... unless someone's come up with a really big breakthrough that everybody up to this point has missed. It's not a hardware problem, it's a semantic problem.

jbri 15y ago
It seems like your complaint is "shitty programmers will still do it wrong". Does this "solve" the concurrency problem so that the most craptastic of copy-pasters can write high-performance concurrent code? Hell no. But it never pretended to in the first place, so that's pretty much irrelevant. It's like saying that doing graphics processing in dedicated hardware is bad because a lot of programmers are awful at coding 3D graphics. Even if you look at this just as a convenience for compiler writers, this would significantly improve the performance for anything that does do transactional memory properly.
- pjscott 15y ago
  It's also a very useful primitive for people writing shared data structures, like concurrent hash tables or multiple-producer, multiple-consumer priority queues.
- jerf 15y ago
  The problem with C arrays is not that shitty programmers get them wrong; the problem with C arrays is that only programming gods walking amongst men get them right. Managing effects in a language without any support for it, and decades of work put into making effects easier to implicitly apply without even having to think about it, is at least as hard. There's more to the programming difficulty scale than "shitty" and "competent" and it's not a good idea to count on any programming technique that can only be used by the gods amongst men... even if you are one! (Writing raw string-concatenation-based HTML output safely is another example. No, you can't do it correctly in a large code base without help. Even if you are that smart, you aren't that superhumanly diligent.)
rbranson 15y ago
I think you misunderstand STM. STM is used to group and apply a few micro-operations, within a single function, but not many or over multiple functions, certainly not over multiple modules. It is not really for rebounding from exceptions in the general sense, as transactions are used in an RDBMS. It's more to keep the system in a stable state, something locks are usually used for in multi-threaded programming. Just as locks are best applied as fine-grained as possible, so is STM.