Is a Java collection guaranteed to be in a valid, usable state after a ConcurrentModificationException? ...
If my opponent casts Ultimate Price on my Phantasmal Bear, can I save it by casting Snap or Curfew?
Can a flute soloist sit?
Why didn't the Event Horizon Telescope team mention Sagittarius A*?
Why isn't the circumferential light around the M87 black hole's event horizon symmetric?
Relationship between Gromov-Witten and Taubes' Gromov invariant
Is it a good practice to use a static variable in a Test Class and use that in the actual class instead of Test.isRunningTest()?
A word that means fill it to the required quantity
Keeping a retro style to sci-fi spaceships?
How to support a colleague who finds meetings extremely tiring?
How do you keep chess fun when your opponent constantly beats you?
How come people say “Would of”?
Is it okay to consider publishing in my first year of PhD?
Output the Arecibo Message
Can we generate random numbers using irrational numbers like π and e?
Loose spokes after only a few rides
How to obtain a position of last non-zero element
APIPA and LAN Broadcast Domain
Dropping list elements from nested list after evaluation
What to do when moving next to a bird sanctuary with a loosely-domesticated cat?
Getting crown tickets for Statue of Liberty
Did the UK government pay "millions and millions of dollars" to try to snag Julian Assange?
Why “相同意思的词” is called “同义词” instead of "同意词"？
How to type a long/em dash `—`
Is Cinnamon a desktop environment or a window manager? (Or both?)
Is a Java collection guaranteed to be in a valid, usable state after a ConcurrentModificationException?
The 2019 Stack Overflow Developer Survey Results Are InWhat is the best way to filter a Java Collection?Iterating through a Collection, avoiding ConcurrentModificationException when removing objects in a loopPyQT and threadsSeparate physics thread without locksBest practice to validate null and empty collection in JavaIs it possible to declare a variable in Gradle usable in Java?C# Concurrent Data Structure which can be Iterated throughJava: how volatile guarantee visibility of “data” in this piece of code?Copying std::vector between threads without lockingParallel stream after collection update
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I am writing a GUI application using the Immediate Mode GUI pattern, and the UI runs on a thread separate to the engine that powers the actual functionality of the application. The GUI thread ends up iterating over many lists of objects that are conceptually "owned" by the engine thread, and these lists change extremely infrequently. The GUI thread is vsync'ed, meaning it runs at about 60Hz, and the engine thread runs at about 200Hz.
Sometimes, actions in the UI will change the contents of the collections in the engine, and I have a message-passing system to post Runnables to the engine thread to do these mutations to ensure that these mutations don't collide with what's happening in the engine. That way, I can ensure that the engine always sees a consistent view of the data, which for my application is very important.
Because the engine is in charge of all data mutations, though, it sometimes happens that the engine changes the contents of a collection while the GUI is iterating through it, and because these collections are standard Java collections, this predictably and correctly throws a ConcurrentModificationException. I can think of a few high-level ways to deal with this:
- locking, either by using a synchronized collection or read-write locks
- double-buffer the data that the GUI thread reads, and have the GUI thread flip the double-buffer when it's done drawing a frame
- ignore the CME and abort drawing the rest of the frame, which will draw partial information for the frame in which the "bad" mutation happens, and just continue on to the next frame
Locking comes with a significant performance penalty, and while it would be fine for the GUI to sometimes stall while waiting to acquire the lock from the engine thread, it is very important for the engine thread to run at a consistent speed, and even an R/W lock would cause stalls in the engine thread. Double-buffering comes with significant complexity, as there is a lot of data that is read by the GUI on each frame.
I give you all of this background because I know that option 3 is ugly, and that my question is in some sense "not the right question". The Javadoc for ConcurrentModificationException even says:
Note that fail-fast behavior cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. Fail-fast operations throw ConcurrentModificationException on a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness: ConcurrentModificationException should be used only to detect bugs.
But! I am not concerned with the correctness of the GUI for the single frame that would be marred by the CME. I am only concerned with what happens on the next frame. Which leads to my question: is it safe to continue using a Java collection (I'm most interested in the answer for ArrayList and HashMap) after a ConcurrentModificationException has been thrown from its iterator? It seems logical that it would be, but I can't find a piece of documentation that says that the object will still be in a usable state after the CME is thrown. Obviously the iterator is toast at that point, but I'd like to swallow the exception and continue using the collection.
java multithreading collections
asked Mar 21 at 18:08
Haldean BrownHaldean Brown
8,22443350
add a comment |
I am writing a GUI application using the Immediate Mode GUI pattern, and the UI runs on a thread separate to the engine that powers the actual functionality of the application. The GUI thread ends up iterating over many lists of objects that are conceptually "owned" by the engine thread, and these lists change extremely infrequently. The GUI thread is vsync'ed, meaning it runs at about 60Hz, and the engine thread runs at about 200Hz.
Sometimes, actions in the UI will change the contents of the collections in the engine, and I have a message-passing system to post Runnables to the engine thread to do these mutations to ensure that these mutations don't collide with what's happening in the engine. That way, I can ensure that the engine always sees a consistent view of the data, which for my application is very important.
Because the engine is in charge of all data mutations, though, it sometimes happens that the engine changes the contents of a collection while the GUI is iterating through it, and because these collections are standard Java collections, this predictably and correctly throws a ConcurrentModificationException. I can think of a few high-level ways to deal with this:
- locking, either by using a synchronized collection or read-write locks
- double-buffer the data that the GUI thread reads, and have the GUI thread flip the double-buffer when it's done drawing a frame
- ignore the CME and abort drawing the rest of the frame, which will draw partial information for the frame in which the "bad" mutation happens, and just continue on to the next frame
Locking comes with a significant performance penalty, and while it would be fine for the GUI to sometimes stall while waiting to acquire the lock from the engine thread, it is very important for the engine thread to run at a consistent speed, and even an R/W lock would cause stalls in the engine thread. Double-buffering comes with significant complexity, as there is a lot of data that is read by the GUI on each frame.
I give you all of this background because I know that option 3 is ugly, and that my question is in some sense "not the right question". The Javadoc for ConcurrentModificationException even says:
Note that fail-fast behavior cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. Fail-fast operations throw ConcurrentModificationException on a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness: ConcurrentModificationException should be used only to detect bugs.
But! I am not concerned with the correctness of the GUI for the single frame that would be marred by the CME. I am only concerned with what happens on the next frame. Which leads to my question: is it safe to continue using a Java collection (I'm most interested in the answer for ArrayList and HashMap) after a ConcurrentModificationException has been thrown from its iterator? It seems logical that it would be, but I can't find a piece of documentation that says that the object will still be in a usable state after the CME is thrown. Obviously the iterator is toast at that point, but I'd like to swallow the exception and continue using the collection.
java multithreading collections
asked Mar 21 at 18:08
Haldean BrownHaldean Brown
8,22443350
add a comment |
I am writing a GUI application using the Immediate Mode GUI pattern, and the UI runs on a thread separate to the engine that powers the actual functionality of the application. The GUI thread ends up iterating over many lists of objects that are conceptually "owned" by the engine thread, and these lists change extremely infrequently. The GUI thread is vsync'ed, meaning it runs at about 60Hz, and the engine thread runs at about 200Hz.
Sometimes, actions in the UI will change the contents of the collections in the engine, and I have a message-passing system to post Runnables to the engine thread to do these mutations to ensure that these mutations don't collide with what's happening in the engine. That way, I can ensure that the engine always sees a consistent view of the data, which for my application is very important.
Because the engine is in charge of all data mutations, though, it sometimes happens that the engine changes the contents of a collection while the GUI is iterating through it, and because these collections are standard Java collections, this predictably and correctly throws a ConcurrentModificationException. I can think of a few high-level ways to deal with this:
- locking, either by using a synchronized collection or read-write locks
- double-buffer the data that the GUI thread reads, and have the GUI thread flip the double-buffer when it's done drawing a frame
- ignore the CME and abort drawing the rest of the frame, which will draw partial information for the frame in which the "bad" mutation happens, and just continue on to the next frame
Locking comes with a significant performance penalty, and while it would be fine for the GUI to sometimes stall while waiting to acquire the lock from the engine thread, it is very important for the engine thread to run at a consistent speed, and even an R/W lock would cause stalls in the engine thread. Double-buffering comes with significant complexity, as there is a lot of data that is read by the GUI on each frame.
I give you all of this background because I know that option 3 is ugly, and that my question is in some sense "not the right question". The Javadoc for ConcurrentModificationException even says:
Note that fail-fast behavior cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. Fail-fast operations throw ConcurrentModificationException on a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness: ConcurrentModificationException should be used only to detect bugs.
But! I am not concerned with the correctness of the GUI for the single frame that would be marred by the CME. I am only concerned with what happens on the next frame. Which leads to my question: is it safe to continue using a Java collection (I'm most interested in the answer for ArrayList and HashMap) after a ConcurrentModificationException has been thrown from its iterator? It seems logical that it would be, but I can't find a piece of documentation that says that the object will still be in a usable state after the CME is thrown. Obviously the iterator is toast at that point, but I'd like to swallow the exception and continue using the collection.
java multithreading collections
asked Mar 21 at 18:08
Haldean BrownHaldean Brown
8,22443350
I am writing a GUI application using the Immediate Mode GUI pattern, and the UI runs on a thread separate to the engine that powers the actual functionality of the application. The GUI thread ends up iterating over many lists of objects that are conceptually "owned" by the engine thread, and these lists change extremely infrequently. The GUI thread is vsync'ed, meaning it runs at about 60Hz, and the engine thread runs at about 200Hz.
Sometimes, actions in the UI will change the contents of the collections in the engine, and I have a message-passing system to post Runnables to the engine thread to do these mutations to ensure that these mutations don't collide with what's happening in the engine. That way, I can ensure that the engine always sees a consistent view of the data, which for my application is very important.
Because the engine is in charge of all data mutations, though, it sometimes happens that the engine changes the contents of a collection while the GUI is iterating through it, and because these collections are standard Java collections, this predictably and correctly throws a ConcurrentModificationException. I can think of a few high-level ways to deal with this:
- locking, either by using a synchronized collection or read-write locks
- double-buffer the data that the GUI thread reads, and have the GUI thread flip the double-buffer when it's done drawing a frame
- ignore the CME and abort drawing the rest of the frame, which will draw partial information for the frame in which the "bad" mutation happens, and just continue on to the next frame
Locking comes with a significant performance penalty, and while it would be fine for the GUI to sometimes stall while waiting to acquire the lock from the engine thread, it is very important for the engine thread to run at a consistent speed, and even an R/W lock would cause stalls in the engine thread. Double-buffering comes with significant complexity, as there is a lot of data that is read by the GUI on each frame.
I give you all of this background because I know that option 3 is ugly, and that my question is in some sense "not the right question". The Javadoc for ConcurrentModificationException even says:
Note that fail-fast behavior cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. Fail-fast operations throw ConcurrentModificationException on a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness: ConcurrentModificationException should be used only to detect bugs.
But! I am not concerned with the correctness of the GUI for the single frame that would be marred by the CME. I am only concerned with what happens on the next frame. Which leads to my question: is it safe to continue using a Java collection (I'm most interested in the answer for ArrayList and HashMap) after a ConcurrentModificationException has been thrown from its iterator? It seems logical that it would be, but I can't find a piece of documentation that says that the object will still be in a usable state after the CME is thrown. Obviously the iterator is toast at that point, but I'd like to swallow the exception and continue using the collection.
java multithreading collections
java multithreading collections
asked Mar 21 at 18:08
Haldean BrownHaldean Brown
8,22443350
asked Mar 21 at 18:08
Haldean BrownHaldean Brown
8,22443350
edited Mar 21 at 18:15
Haldean Brown
asked Mar 21 at 18:08
Haldean BrownHaldean Brown
8,22443350
asked Mar 21 at 18:08
Haldean BrownHaldean Brown
8,22443350
asked Mar 21 at 18:08
Haldean BrownHaldean Brown
8,22443350
8,22443350
add a comment |
add a comment |
4 Answers
4
active
oldest
votes
For most collections, as long as you only have one writer, you are probably ok, but there are no guarantees. If you have multiple writers on a HashMap you can end up with a corrupt map which has an infinite loop in it's structure.
I suggest you use ReentrantLock which has a tryLock() method if you want to support only-obtaining-a-lock-if-it's-not-being-used approach to minimise blocking.
Another way to feed data from one thread to another is to Queue modification tasks which the engine can pick up when not otherwise busy. This allows all access through one thread only.
BTW: A lock/unlock takes around 1 micro-second which is unlikely to make much difference to you unless you do this a lot.
answered Mar 21 at 18:25
Peter LawreyPeter Lawrey
449k56576979
3
Having multiple writers will not causeConcurrentModificationException. Although the name makes it sound like a multi-threading exception, it is not. Single-threaded code can cause the exception too. --- E.g. having multiple writers on a HashMap, which may corrupt the map, will not cause the exception unless you're iterating it too, and lots of maps are never iterated. --- I believe your answer is missing the point ofConcurrentModificationException.
– Andreas
Mar 21 at 18:28
1
I am queueing the modifications, but the issue is that both threads are reading heavily from this shared data, so one of them is always going to lose. TheReentrantLockis an interesting idea, because the engine could just defer the modification task to the next loop if the GUI thread is currently using the collection.
– Haldean Brown
Mar 21 at 18:29
@HaldeanBrown You need to queue the entire task, both the reading and writing should be performed by only one thread if you want to avoid locking, or you have to use locking, or your data must be read-only.
– Peter Lawrey
Mar 21 at 18:30
2
@Andreas I am trying to solve the OP design problem rather than explaining what ConcurrentModificationException means, though you are correct and have a point, I don't think it helps the OP.
– Peter Lawrey
Mar 21 at 18:31
I think the reentrant lock to "reject" mutations until they can go through without blocking is the way to go, if locking is that cheap. When I prototyped a solution with locks I saw the engine get much slower, but now I'm thinking I must have made a mistake when I did that. Thank you Peter!
– Haldean Brown
Mar 21 at 18:39
|
show 3 more comments
Quoting part of the quote:
Therefore, it would be wrong to write a program that depended on this exception for its correctness: ConcurrentModificationException should be used only to detect bugs.
Conclusion: Your code is buggy and needs to be fixed, so it doesn't matter what state the collection is in.
You should never get that error in valid code. It's an exception that should never be caught and acted on.
answered Mar 21 at 18:25
AndreasAndreas
79.9k465129
This is not an answer to my question, but am I correct in inferring that your actual answer is that the collection is in an undefined state, and thus should be considered unusable?
– Haldean Brown
Mar 21 at 18:31
3
@HaldeanBrown I'm saying that you should never code around aConcurrentModificationException. The exception it a non-guaranteed fast-fail that simply tells you, the programmer, that you've written bad code and the code needs to be fixed. The only correct action when receiving that error is to fix the code, not to add hacky code to work around it. The fact that you're even contemplating doing so mean that you missed the highlighted part of the quote, and that's what this answer is trying to teach you.
– Andreas
Mar 21 at 18:34
I think what Andreas is saying is that we don't actually know if the collection is unstable or unusable, or not. All we know for sure is that it's an error, and the code needs to be corrected. I'm pretty sure it's implementation dependent. If you look at the code for a collection today, the data might be fine, and then tomorrow Oracle decides to change their implementation and it completely messes you up.
– markspace
Mar 21 at 18:39
3
@markspace Actually,ConcurrentModificationExceptiononly says that the collection was modified directly, while it was being iterated. It in no way, shape, or form is about whether that modification was incorrectly done. It just says that theIteratoris no longer valid. Multi-threaded update of a collection that is not thread-safe will not cause that exception, it will just silently corrupt the collection. The exception is not about thread-safety, regardless of the exception name.
– Andreas
Mar 21 at 18:52
That's completely right, and this is a thing I should add to my question; it is true that what I'm talking about is not about thread-safety, because my issue would still crop up if I were using synchronized collections. I could do all of my reads and writes in a thread-safe way but still have the problem with iterators that I'm having now.
– Haldean Brown
Mar 21 at 19:08
add a comment |
The GUI thread ends up iterating over many lists of objects that are conceptually "owned" by the engine thread
Since the engine owns the data I argue that it should not openly share that data with the GUI.
Consider having the engine push data to the GUI rather than the GUI pulling (or reading directly) from the engines data structures. That way the engine has full and exclusive control of its data, as it probably should.
The downside is that this may take a significant redesign.
But the benefits may be significant enough to warrant it:
- No more
ConcurrentModificationException
- No need for locks
- No need to constantly scan data and redraw, only when an update says to.
The last point could be significant depending on how much data you are dealing with or how complex your redrawing is. Pushing updates to your GUI will give you much more flexibility to optimize if profiling reveals the need to do so. For example, you could make better use of caches on the GUI side and invalidate those caches through updates pushed from the engine.
answered Mar 21 at 18:42
xtraticxtratic
2,5841824
add a comment |
Locking comes with a significant performance penalty
Does it really? Have you seen if putting in a rudimentary gate/guard/lock/semaphore kills performance? At 60Hz/200Hz it's unlikely to do so.
answered Mar 21 at 18:30
Not a JDNot a JD
1,175112
My first pass at using locking came with a ~10% performance penalty; the problem is that the engine is a complex piece of code that accesses all of these collections in a bunch of different places, so I end up doing a lot of locking and unlocking. I could probably do a cleverer thing with fewer, larger blocks to reduce the performance penalty, but I got sticker shock after seeing the 10%.
– Haldean Brown
Mar 21 at 18:34
I just saw Peter's edit saying that (un)locking should be near-instantaneous, which makes me wonder if I did a dumb thing when I wrote my locking implementation..
– Haldean Brown
Mar 21 at 18:35
Just for your edification, try creating a simple driver class with a main method that leverages a bunch of different locking paradigms/primitives (synchronized, the lock types etc). A 10% performance penalty smells like something isn't quite right on the implementation side. Did you run your code through a profiler? Is your use case write-heavy?
– Not a JD
Mar 21 at 18:39
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55286705%2fis-a-java-collection-guaranteed-to-be-in-a-valid-usable-state-after-a-concurren%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
For most collections, as long as you only have one writer, you are probably ok, but there are no guarantees. If you have multiple writers on a HashMap you can end up with a corrupt map which has an infinite loop in it's structure.
I suggest you use ReentrantLock which has a tryLock() method if you want to support only-obtaining-a-lock-if-it's-not-being-used approach to minimise blocking.
Another way to feed data from one thread to another is to Queue modification tasks which the engine can pick up when not otherwise busy. This allows all access through one thread only.
BTW: A lock/unlock takes around 1 micro-second which is unlikely to make much difference to you unless you do this a lot.
answered Mar 21 at 18:25
Peter LawreyPeter Lawrey
449k56576979
3
Having multiple writers will not causeConcurrentModificationException. Although the name makes it sound like a multi-threading exception, it is not. Single-threaded code can cause the exception too. --- E.g. having multiple writers on a HashMap, which may corrupt the map, will not cause the exception unless you're iterating it too, and lots of maps are never iterated. --- I believe your answer is missing the point ofConcurrentModificationException.
– Andreas
Mar 21 at 18:28
1
I am queueing the modifications, but the issue is that both threads are reading heavily from this shared data, so one of them is always going to lose. TheReentrantLockis an interesting idea, because the engine could just defer the modification task to the next loop if the GUI thread is currently using the collection.
– Haldean Brown
Mar 21 at 18:29
@HaldeanBrown You need to queue the entire task, both the reading and writing should be performed by only one thread if you want to avoid locking, or you have to use locking, or your data must be read-only.
– Peter Lawrey
Mar 21 at 18:30
2
@Andreas I am trying to solve the OP design problem rather than explaining what ConcurrentModificationException means, though you are correct and have a point, I don't think it helps the OP.
– Peter Lawrey
Mar 21 at 18:31
I think the reentrant lock to "reject" mutations until they can go through without blocking is the way to go, if locking is that cheap. When I prototyped a solution with locks I saw the engine get much slower, but now I'm thinking I must have made a mistake when I did that. Thank you Peter!
– Haldean Brown
Mar 21 at 18:39
|
show 3 more comments
For most collections, as long as you only have one writer, you are probably ok, but there are no guarantees. If you have multiple writers on a HashMap you can end up with a corrupt map which has an infinite loop in it's structure.
I suggest you use ReentrantLock which has a tryLock() method if you want to support only-obtaining-a-lock-if-it's-not-being-used approach to minimise blocking.
Another way to feed data from one thread to another is to Queue modification tasks which the engine can pick up when not otherwise busy. This allows all access through one thread only.
BTW: A lock/unlock takes around 1 micro-second which is unlikely to make much difference to you unless you do this a lot.
answered Mar 21 at 18:25
Peter LawreyPeter Lawrey
449k56576979
3
Having multiple writers will not causeConcurrentModificationException. Although the name makes it sound like a multi-threading exception, it is not. Single-threaded code can cause the exception too. --- E.g. having multiple writers on a HashMap, which may corrupt the map, will not cause the exception unless you're iterating it too, and lots of maps are never iterated. --- I believe your answer is missing the point ofConcurrentModificationException.
– Andreas
Mar 21 at 18:28
1
I am queueing the modifications, but the issue is that both threads are reading heavily from this shared data, so one of them is always going to lose. TheReentrantLockis an interesting idea, because the engine could just defer the modification task to the next loop if the GUI thread is currently using the collection.
– Haldean Brown
Mar 21 at 18:29
@HaldeanBrown You need to queue the entire task, both the reading and writing should be performed by only one thread if you want to avoid locking, or you have to use locking, or your data must be read-only.
– Peter Lawrey
Mar 21 at 18:30
2
@Andreas I am trying to solve the OP design problem rather than explaining what ConcurrentModificationException means, though you are correct and have a point, I don't think it helps the OP.
– Peter Lawrey
Mar 21 at 18:31
I think the reentrant lock to "reject" mutations until they can go through without blocking is the way to go, if locking is that cheap. When I prototyped a solution with locks I saw the engine get much slower, but now I'm thinking I must have made a mistake when I did that. Thank you Peter!
– Haldean Brown
Mar 21 at 18:39
|
show 3 more comments
For most collections, as long as you only have one writer, you are probably ok, but there are no guarantees. If you have multiple writers on a HashMap you can end up with a corrupt map which has an infinite loop in it's structure.
I suggest you use ReentrantLock which has a tryLock() method if you want to support only-obtaining-a-lock-if-it's-not-being-used approach to minimise blocking.
Another way to feed data from one thread to another is to Queue modification tasks which the engine can pick up when not otherwise busy. This allows all access through one thread only.
BTW: A lock/unlock takes around 1 micro-second which is unlikely to make much difference to you unless you do this a lot.
answered Mar 21 at 18:25
Peter LawreyPeter Lawrey
449k56576979
For most collections, as long as you only have one writer, you are probably ok, but there are no guarantees. If you have multiple writers on a HashMap you can end up with a corrupt map which has an infinite loop in it's structure.
I suggest you use ReentrantLock which has a tryLock() method if you want to support only-obtaining-a-lock-if-it's-not-being-used approach to minimise blocking.
Another way to feed data from one thread to another is to Queue modification tasks which the engine can pick up when not otherwise busy. This allows all access through one thread only.
BTW: A lock/unlock takes around 1 micro-second which is unlikely to make much difference to you unless you do this a lot.
answered Mar 21 at 18:25
Peter LawreyPeter Lawrey
449k56576979
edited Mar 21 at 18:33
answered Mar 21 at 18:25
Peter LawreyPeter Lawrey
449k56576979
answered Mar 21 at 18:25
Peter LawreyPeter Lawrey
449k56576979
answered Mar 21 at 18:25
Peter LawreyPeter Lawrey
449k56576979
449k56576979
3
Having multiple writers will not causeConcurrentModificationException. Although the name makes it sound like a multi-threading exception, it is not. Single-threaded code can cause the exception too. --- E.g. having multiple writers on a HashMap, which may corrupt the map, will not cause the exception unless you're iterating it too, and lots of maps are never iterated. --- I believe your answer is missing the point ofConcurrentModificationException.
– Andreas
Mar 21 at 18:28
1
I am queueing the modifications, but the issue is that both threads are reading heavily from this shared data, so one of them is always going to lose. TheReentrantLockis an interesting idea, because the engine could just defer the modification task to the next loop if the GUI thread is currently using the collection.
– Haldean Brown
Mar 21 at 18:29
@HaldeanBrown You need to queue the entire task, both the reading and writing should be performed by only one thread if you want to avoid locking, or you have to use locking, or your data must be read-only.
– Peter Lawrey
Mar 21 at 18:30
2
@Andreas I am trying to solve the OP design problem rather than explaining what ConcurrentModificationException means, though you are correct and have a point, I don't think it helps the OP.
– Peter Lawrey
Mar 21 at 18:31
I think the reentrant lock to "reject" mutations until they can go through without blocking is the way to go, if locking is that cheap. When I prototyped a solution with locks I saw the engine get much slower, but now I'm thinking I must have made a mistake when I did that. Thank you Peter!
– Haldean Brown
Mar 21 at 18:39
|
show 3 more comments
3
Having multiple writers will not causeConcurrentModificationException. Although the name makes it sound like a multi-threading exception, it is not. Single-threaded code can cause the exception too. --- E.g. having multiple writers on a HashMap, which may corrupt the map, will not cause the exception unless you're iterating it too, and lots of maps are never iterated. --- I believe your answer is missing the point ofConcurrentModificationException.
– Andreas
Mar 21 at 18:28
1
I am queueing the modifications, but the issue is that both threads are reading heavily from this shared data, so one of them is always going to lose. TheReentrantLockis an interesting idea, because the engine could just defer the modification task to the next loop if the GUI thread is currently using the collection.
– Haldean Brown
Mar 21 at 18:29
@HaldeanBrown You need to queue the entire task, both the reading and writing should be performed by only one thread if you want to avoid locking, or you have to use locking, or your data must be read-only.
– Peter Lawrey
Mar 21 at 18:30
2
@Andreas I am trying to solve the OP design problem rather than explaining what ConcurrentModificationException means, though you are correct and have a point, I don't think it helps the OP.
– Peter Lawrey
Mar 21 at 18:31
I think the reentrant lock to "reject" mutations until they can go through without blocking is the way to go, if locking is that cheap. When I prototyped a solution with locks I saw the engine get much slower, but now I'm thinking I must have made a mistake when I did that. Thank you Peter!
– Haldean Brown
Mar 21 at 18:39
3
3
Having multiple writers will not cause
ConcurrentModificationException. Although the name makes it sound like a multi-threading exception, it is not. Single-threaded code can cause the exception too. --- E.g. having multiple writers on a HashMap, which may corrupt the map, will not cause the exception unless you're iterating it too, and lots of maps are never iterated. --- I believe your answer is missing the point of ConcurrentModificationException.– Andreas
Mar 21 at 18:28
Having multiple writers will not cause
ConcurrentModificationException. Although the name makes it sound like a multi-threading exception, it is not. Single-threaded code can cause the exception too. --- E.g. having multiple writers on a HashMap, which may corrupt the map, will not cause the exception unless you're iterating it too, and lots of maps are never iterated. --- I believe your answer is missing the point of ConcurrentModificationException.– Andreas
Mar 21 at 18:28
1
1
I am queueing the modifications, but the issue is that both threads are reading heavily from this shared data, so one of them is always going to lose. The
ReentrantLock is an interesting idea, because the engine could just defer the modification task to the next loop if the GUI thread is currently using the collection.– Haldean Brown
Mar 21 at 18:29
I am queueing the modifications, but the issue is that both threads are reading heavily from this shared data, so one of them is always going to lose. The
ReentrantLock is an interesting idea, because the engine could just defer the modification task to the next loop if the GUI thread is currently using the collection.– Haldean Brown
Mar 21 at 18:29
@HaldeanBrown You need to queue the entire task, both the reading and writing should be performed by only one thread if you want to avoid locking, or you have to use locking, or your data must be read-only.
– Peter Lawrey
Mar 21 at 18:30
@HaldeanBrown You need to queue the entire task, both the reading and writing should be performed by only one thread if you want to avoid locking, or you have to use locking, or your data must be read-only.
– Peter Lawrey
Mar 21 at 18:30
2
2
@Andreas I am trying to solve the OP design problem rather than explaining what ConcurrentModificationException means, though you are correct and have a point, I don't think it helps the OP.
– Peter Lawrey
Mar 21 at 18:31
@Andreas I am trying to solve the OP design problem rather than explaining what ConcurrentModificationException means, though you are correct and have a point, I don't think it helps the OP.
– Peter Lawrey
Mar 21 at 18:31
I think the reentrant lock to "reject" mutations until they can go through without blocking is the way to go, if locking is that cheap. When I prototyped a solution with locks I saw the engine get much slower, but now I'm thinking I must have made a mistake when I did that. Thank you Peter!
– Haldean Brown
Mar 21 at 18:39
I think the reentrant lock to "reject" mutations until they can go through without blocking is the way to go, if locking is that cheap. When I prototyped a solution with locks I saw the engine get much slower, but now I'm thinking I must have made a mistake when I did that. Thank you Peter!
– Haldean Brown
Mar 21 at 18:39
|
show 3 more comments
Quoting part of the quote:
Therefore, it would be wrong to write a program that depended on this exception for its correctness: ConcurrentModificationException should be used only to detect bugs.
Conclusion: Your code is buggy and needs to be fixed, so it doesn't matter what state the collection is in.
You should never get that error in valid code. It's an exception that should never be caught and acted on.
answered Mar 21 at 18:25
AndreasAndreas
79.9k465129
This is not an answer to my question, but am I correct in inferring that your actual answer is that the collection is in an undefined state, and thus should be considered unusable?
– Haldean Brown
Mar 21 at 18:31
3
@HaldeanBrown I'm saying that you should never code around aConcurrentModificationException. The exception it a non-guaranteed fast-fail that simply tells you, the programmer, that you've written bad code and the code needs to be fixed. The only correct action when receiving that error is to fix the code, not to add hacky code to work around it. The fact that you're even contemplating doing so mean that you missed the highlighted part of the quote, and that's what this answer is trying to teach you.
– Andreas
Mar 21 at 18:34
I think what Andreas is saying is that we don't actually know if the collection is unstable or unusable, or not. All we know for sure is that it's an error, and the code needs to be corrected. I'm pretty sure it's implementation dependent. If you look at the code for a collection today, the data might be fine, and then tomorrow Oracle decides to change their implementation and it completely messes you up.
– markspace
Mar 21 at 18:39
3
@markspace Actually,ConcurrentModificationExceptiononly says that the collection was modified directly, while it was being iterated. It in no way, shape, or form is about whether that modification was incorrectly done. It just says that theIteratoris no longer valid. Multi-threaded update of a collection that is not thread-safe will not cause that exception, it will just silently corrupt the collection. The exception is not about thread-safety, regardless of the exception name.
– Andreas
Mar 21 at 18:52
That's completely right, and this is a thing I should add to my question; it is true that what I'm talking about is not about thread-safety, because my issue would still crop up if I were using synchronized collections. I could do all of my reads and writes in a thread-safe way but still have the problem with iterators that I'm having now.
– Haldean Brown
Mar 21 at 19:08
add a comment |
Quoting part of the quote:
Therefore, it would be wrong to write a program that depended on this exception for its correctness: ConcurrentModificationException should be used only to detect bugs.
Conclusion: Your code is buggy and needs to be fixed, so it doesn't matter what state the collection is in.
You should never get that error in valid code. It's an exception that should never be caught and acted on.
answered Mar 21 at 18:25
AndreasAndreas
79.9k465129
This is not an answer to my question, but am I correct in inferring that your actual answer is that the collection is in an undefined state, and thus should be considered unusable?
– Haldean Brown
Mar 21 at 18:31
3
@HaldeanBrown I'm saying that you should never code around aConcurrentModificationException. The exception it a non-guaranteed fast-fail that simply tells you, the programmer, that you've written bad code and the code needs to be fixed. The only correct action when receiving that error is to fix the code, not to add hacky code to work around it. The fact that you're even contemplating doing so mean that you missed the highlighted part of the quote, and that's what this answer is trying to teach you.
– Andreas
Mar 21 at 18:34
I think what Andreas is saying is that we don't actually know if the collection is unstable or unusable, or not. All we know for sure is that it's an error, and the code needs to be corrected. I'm pretty sure it's implementation dependent. If you look at the code for a collection today, the data might be fine, and then tomorrow Oracle decides to change their implementation and it completely messes you up.
– markspace
Mar 21 at 18:39
3
@markspace Actually,ConcurrentModificationExceptiononly says that the collection was modified directly, while it was being iterated. It in no way, shape, or form is about whether that modification was incorrectly done. It just says that theIteratoris no longer valid. Multi-threaded update of a collection that is not thread-safe will not cause that exception, it will just silently corrupt the collection. The exception is not about thread-safety, regardless of the exception name.
– Andreas
Mar 21 at 18:52
That's completely right, and this is a thing I should add to my question; it is true that what I'm talking about is not about thread-safety, because my issue would still crop up if I were using synchronized collections. I could do all of my reads and writes in a thread-safe way but still have the problem with iterators that I'm having now.
– Haldean Brown
Mar 21 at 19:08
add a comment |
Quoting part of the quote:
Therefore, it would be wrong to write a program that depended on this exception for its correctness: ConcurrentModificationException should be used only to detect bugs.
Conclusion: Your code is buggy and needs to be fixed, so it doesn't matter what state the collection is in.
You should never get that error in valid code. It's an exception that should never be caught and acted on.
answered Mar 21 at 18:25
AndreasAndreas
79.9k465129
Quoting part of the quote:
Therefore, it would be wrong to write a program that depended on this exception for its correctness: ConcurrentModificationException should be used only to detect bugs.
Conclusion: Your code is buggy and needs to be fixed, so it doesn't matter what state the collection is in.
You should never get that error in valid code. It's an exception that should never be caught and acted on.
answered Mar 21 at 18:25
AndreasAndreas
79.9k465129
answered Mar 21 at 18:25
AndreasAndreas
79.9k465129
answered Mar 21 at 18:25
AndreasAndreas
79.9k465129
answered Mar 21 at 18:25
AndreasAndreas
79.9k465129
79.9k465129
This is not an answer to my question, but am I correct in inferring that your actual answer is that the collection is in an undefined state, and thus should be considered unusable?
– Haldean Brown
Mar 21 at 18:31
3
@HaldeanBrown I'm saying that you should never code around aConcurrentModificationException. The exception it a non-guaranteed fast-fail that simply tells you, the programmer, that you've written bad code and the code needs to be fixed. The only correct action when receiving that error is to fix the code, not to add hacky code to work around it. The fact that you're even contemplating doing so mean that you missed the highlighted part of the quote, and that's what this answer is trying to teach you.
– Andreas
Mar 21 at 18:34
I think what Andreas is saying is that we don't actually know if the collection is unstable or unusable, or not. All we know for sure is that it's an error, and the code needs to be corrected. I'm pretty sure it's implementation dependent. If you look at the code for a collection today, the data might be fine, and then tomorrow Oracle decides to change their implementation and it completely messes you up.
– markspace
Mar 21 at 18:39
3
@markspace Actually,ConcurrentModificationExceptiononly says that the collection was modified directly, while it was being iterated. It in no way, shape, or form is about whether that modification was incorrectly done. It just says that theIteratoris no longer valid. Multi-threaded update of a collection that is not thread-safe will not cause that exception, it will just silently corrupt the collection. The exception is not about thread-safety, regardless of the exception name.
– Andreas
Mar 21 at 18:52
That's completely right, and this is a thing I should add to my question; it is true that what I'm talking about is not about thread-safety, because my issue would still crop up if I were using synchronized collections. I could do all of my reads and writes in a thread-safe way but still have the problem with iterators that I'm having now.
– Haldean Brown
Mar 21 at 19:08
add a comment |
This is not an answer to my question, but am I correct in inferring that your actual answer is that the collection is in an undefined state, and thus should be considered unusable?
– Haldean Brown
Mar 21 at 18:31
3
@HaldeanBrown I'm saying that you should never code around aConcurrentModificationException. The exception it a non-guaranteed fast-fail that simply tells you, the programmer, that you've written bad code and the code needs to be fixed. The only correct action when receiving that error is to fix the code, not to add hacky code to work around it. The fact that you're even contemplating doing so mean that you missed the highlighted part of the quote, and that's what this answer is trying to teach you.
– Andreas
Mar 21 at 18:34
I think what Andreas is saying is that we don't actually know if the collection is unstable or unusable, or not. All we know for sure is that it's an error, and the code needs to be corrected. I'm pretty sure it's implementation dependent. If you look at the code for a collection today, the data might be fine, and then tomorrow Oracle decides to change their implementation and it completely messes you up.
– markspace
Mar 21 at 18:39
3
@markspace Actually,ConcurrentModificationExceptiononly says that the collection was modified directly, while it was being iterated. It in no way, shape, or form is about whether that modification was incorrectly done. It just says that theIteratoris no longer valid. Multi-threaded update of a collection that is not thread-safe will not cause that exception, it will just silently corrupt the collection. The exception is not about thread-safety, regardless of the exception name.
– Andreas
Mar 21 at 18:52
That's completely right, and this is a thing I should add to my question; it is true that what I'm talking about is not about thread-safety, because my issue would still crop up if I were using synchronized collections. I could do all of my reads and writes in a thread-safe way but still have the problem with iterators that I'm having now.
– Haldean Brown
Mar 21 at 19:08
This is not an answer to my question, but am I correct in inferring that your actual answer is that the collection is in an undefined state, and thus should be considered unusable?
– Haldean Brown
Mar 21 at 18:31
This is not an answer to my question, but am I correct in inferring that your actual answer is that the collection is in an undefined state, and thus should be considered unusable?
– Haldean Brown
Mar 21 at 18:31
3
3
@HaldeanBrown I'm saying that you should never code around a
ConcurrentModificationException. The exception it a non-guaranteed fast-fail that simply tells you, the programmer, that you've written bad code and the code needs to be fixed. The only correct action when receiving that error is to fix the code, not to add hacky code to work around it. The fact that you're even contemplating doing so mean that you missed the highlighted part of the quote, and that's what this answer is trying to teach you.– Andreas
Mar 21 at 18:34
@HaldeanBrown I'm saying that you should never code around a
ConcurrentModificationException. The exception it a non-guaranteed fast-fail that simply tells you, the programmer, that you've written bad code and the code needs to be fixed. The only correct action when receiving that error is to fix the code, not to add hacky code to work around it. The fact that you're even contemplating doing so mean that you missed the highlighted part of the quote, and that's what this answer is trying to teach you.– Andreas
Mar 21 at 18:34
I think what Andreas is saying is that we don't actually know if the collection is unstable or unusable, or not. All we know for sure is that it's an error, and the code needs to be corrected. I'm pretty sure it's implementation dependent. If you look at the code for a collection today, the data might be fine, and then tomorrow Oracle decides to change their implementation and it completely messes you up.
– markspace
Mar 21 at 18:39
I think what Andreas is saying is that we don't actually know if the collection is unstable or unusable, or not. All we know for sure is that it's an error, and the code needs to be corrected. I'm pretty sure it's implementation dependent. If you look at the code for a collection today, the data might be fine, and then tomorrow Oracle decides to change their implementation and it completely messes you up.
– markspace
Mar 21 at 18:39
3
3
@markspace Actually,
ConcurrentModificationException only says that the collection was modified directly, while it was being iterated. It in no way, shape, or form is about whether that modification was incorrectly done. It just says that the Iterator is no longer valid. Multi-threaded update of a collection that is not thread-safe will not cause that exception, it will just silently corrupt the collection. The exception is not about thread-safety, regardless of the exception name.– Andreas
Mar 21 at 18:52
@markspace Actually,
ConcurrentModificationException only says that the collection was modified directly, while it was being iterated. It in no way, shape, or form is about whether that modification was incorrectly done. It just says that the Iterator is no longer valid. Multi-threaded update of a collection that is not thread-safe will not cause that exception, it will just silently corrupt the collection. The exception is not about thread-safety, regardless of the exception name.– Andreas
Mar 21 at 18:52
That's completely right, and this is a thing I should add to my question; it is true that what I'm talking about is not about thread-safety, because my issue would still crop up if I were using synchronized collections. I could do all of my reads and writes in a thread-safe way but still have the problem with iterators that I'm having now.
– Haldean Brown
Mar 21 at 19:08
That's completely right, and this is a thing I should add to my question; it is true that what I'm talking about is not about thread-safety, because my issue would still crop up if I were using synchronized collections. I could do all of my reads and writes in a thread-safe way but still have the problem with iterators that I'm having now.
– Haldean Brown
Mar 21 at 19:08
add a comment |
The GUI thread ends up iterating over many lists of objects that are conceptually "owned" by the engine thread
Since the engine owns the data I argue that it should not openly share that data with the GUI.
Consider having the engine push data to the GUI rather than the GUI pulling (or reading directly) from the engines data structures. That way the engine has full and exclusive control of its data, as it probably should.
The downside is that this may take a significant redesign.
But the benefits may be significant enough to warrant it:
- No more
ConcurrentModificationException
- No need for locks
- No need to constantly scan data and redraw, only when an update says to.
The last point could be significant depending on how much data you are dealing with or how complex your redrawing is. Pushing updates to your GUI will give you much more flexibility to optimize if profiling reveals the need to do so. For example, you could make better use of caches on the GUI side and invalidate those caches through updates pushed from the engine.
answered Mar 21 at 18:42
xtraticxtratic
2,5841824
add a comment |
The GUI thread ends up iterating over many lists of objects that are conceptually "owned" by the engine thread
Since the engine owns the data I argue that it should not openly share that data with the GUI.
Consider having the engine push data to the GUI rather than the GUI pulling (or reading directly) from the engines data structures. That way the engine has full and exclusive control of its data, as it probably should.
The downside is that this may take a significant redesign.
But the benefits may be significant enough to warrant it:
- No more
ConcurrentModificationException
- No need for locks
- No need to constantly scan data and redraw, only when an update says to.
The last point could be significant depending on how much data you are dealing with or how complex your redrawing is. Pushing updates to your GUI will give you much more flexibility to optimize if profiling reveals the need to do so. For example, you could make better use of caches on the GUI side and invalidate those caches through updates pushed from the engine.
answered Mar 21 at 18:42
xtraticxtratic
2,5841824
add a comment |
The GUI thread ends up iterating over many lists of objects that are conceptually "owned" by the engine thread
Since the engine owns the data I argue that it should not openly share that data with the GUI.
Consider having the engine push data to the GUI rather than the GUI pulling (or reading directly) from the engines data structures. That way the engine has full and exclusive control of its data, as it probably should.
The downside is that this may take a significant redesign.
But the benefits may be significant enough to warrant it:
- No more
ConcurrentModificationException
- No need for locks
- No need to constantly scan data and redraw, only when an update says to.
The last point could be significant depending on how much data you are dealing with or how complex your redrawing is. Pushing updates to your GUI will give you much more flexibility to optimize if profiling reveals the need to do so. For example, you could make better use of caches on the GUI side and invalidate those caches through updates pushed from the engine.
answered Mar 21 at 18:42
xtraticxtratic
2,5841824
The GUI thread ends up iterating over many lists of objects that are conceptually "owned" by the engine thread
Since the engine owns the data I argue that it should not openly share that data with the GUI.
Consider having the engine push data to the GUI rather than the GUI pulling (or reading directly) from the engines data structures. That way the engine has full and exclusive control of its data, as it probably should.
The downside is that this may take a significant redesign.
But the benefits may be significant enough to warrant it:
- No more
ConcurrentModificationException
- No need for locks
- No need to constantly scan data and redraw, only when an update says to.
The last point could be significant depending on how much data you are dealing with or how complex your redrawing is. Pushing updates to your GUI will give you much more flexibility to optimize if profiling reveals the need to do so. For example, you could make better use of caches on the GUI side and invalidate those caches through updates pushed from the engine.
answered Mar 21 at 18:42
xtraticxtratic
2,5841824
edited Mar 21 at 19:43
answered Mar 21 at 18:42
xtraticxtratic
2,5841824
answered Mar 21 at 18:42
xtraticxtratic
2,5841824
answered Mar 21 at 18:42
xtraticxtratic
2,5841824
2,5841824
add a comment |
add a comment |
Locking comes with a significant performance penalty
Does it really? Have you seen if putting in a rudimentary gate/guard/lock/semaphore kills performance? At 60Hz/200Hz it's unlikely to do so.
answered Mar 21 at 18:30
Not a JDNot a JD
1,175112
My first pass at using locking came with a ~10% performance penalty; the problem is that the engine is a complex piece of code that accesses all of these collections in a bunch of different places, so I end up doing a lot of locking and unlocking. I could probably do a cleverer thing with fewer, larger blocks to reduce the performance penalty, but I got sticker shock after seeing the 10%.
– Haldean Brown
Mar 21 at 18:34
I just saw Peter's edit saying that (un)locking should be near-instantaneous, which makes me wonder if I did a dumb thing when I wrote my locking implementation..
– Haldean Brown
Mar 21 at 18:35
Just for your edification, try creating a simple driver class with a main method that leverages a bunch of different locking paradigms/primitives (synchronized, the lock types etc). A 10% performance penalty smells like something isn't quite right on the implementation side. Did you run your code through a profiler? Is your use case write-heavy?
– Not a JD
Mar 21 at 18:39
add a comment |
Locking comes with a significant performance penalty
Does it really? Have you seen if putting in a rudimentary gate/guard/lock/semaphore kills performance? At 60Hz/200Hz it's unlikely to do so.
answered Mar 21 at 18:30
Not a JDNot a JD
1,175112
My first pass at using locking came with a ~10% performance penalty; the problem is that the engine is a complex piece of code that accesses all of these collections in a bunch of different places, so I end up doing a lot of locking and unlocking. I could probably do a cleverer thing with fewer, larger blocks to reduce the performance penalty, but I got sticker shock after seeing the 10%.
– Haldean Brown
Mar 21 at 18:34
I just saw Peter's edit saying that (un)locking should be near-instantaneous, which makes me wonder if I did a dumb thing when I wrote my locking implementation..
– Haldean Brown
Mar 21 at 18:35
Just for your edification, try creating a simple driver class with a main method that leverages a bunch of different locking paradigms/primitives (synchronized, the lock types etc). A 10% performance penalty smells like something isn't quite right on the implementation side. Did you run your code through a profiler? Is your use case write-heavy?
– Not a JD
Mar 21 at 18:39
add a comment |
Locking comes with a significant performance penalty
Does it really? Have you seen if putting in a rudimentary gate/guard/lock/semaphore kills performance? At 60Hz/200Hz it's unlikely to do so.
answered Mar 21 at 18:30
Not a JDNot a JD
1,175112
Locking comes with a significant performance penalty
Does it really? Have you seen if putting in a rudimentary gate/guard/lock/semaphore kills performance? At 60Hz/200Hz it's unlikely to do so.
answered Mar 21 at 18:30
Not a JDNot a JD
1,175112
answered Mar 21 at 18:30
Not a JDNot a JD
1,175112
answered Mar 21 at 18:30
Not a JDNot a JD
1,175112
answered Mar 21 at 18:30
Not a JDNot a JD
1,175112
1,175112
My first pass at using locking came with a ~10% performance penalty; the problem is that the engine is a complex piece of code that accesses all of these collections in a bunch of different places, so I end up doing a lot of locking and unlocking. I could probably do a cleverer thing with fewer, larger blocks to reduce the performance penalty, but I got sticker shock after seeing the 10%.
– Haldean Brown
Mar 21 at 18:34
I just saw Peter's edit saying that (un)locking should be near-instantaneous, which makes me wonder if I did a dumb thing when I wrote my locking implementation..
– Haldean Brown
Mar 21 at 18:35
Just for your edification, try creating a simple driver class with a main method that leverages a bunch of different locking paradigms/primitives (synchronized, the lock types etc). A 10% performance penalty smells like something isn't quite right on the implementation side. Did you run your code through a profiler? Is your use case write-heavy?
– Not a JD
Mar 21 at 18:39
add a comment |
My first pass at using locking came with a ~10% performance penalty; the problem is that the engine is a complex piece of code that accesses all of these collections in a bunch of different places, so I end up doing a lot of locking and unlocking. I could probably do a cleverer thing with fewer, larger blocks to reduce the performance penalty, but I got sticker shock after seeing the 10%.
– Haldean Brown
Mar 21 at 18:34
I just saw Peter's edit saying that (un)locking should be near-instantaneous, which makes me wonder if I did a dumb thing when I wrote my locking implementation..
– Haldean Brown
Mar 21 at 18:35
Just for your edification, try creating a simple driver class with a main method that leverages a bunch of different locking paradigms/primitives (synchronized, the lock types etc). A 10% performance penalty smells like something isn't quite right on the implementation side. Did you run your code through a profiler? Is your use case write-heavy?
– Not a JD
Mar 21 at 18:39
My first pass at using locking came with a ~10% performance penalty; the problem is that the engine is a complex piece of code that accesses all of these collections in a bunch of different places, so I end up doing a lot of locking and unlocking. I could probably do a cleverer thing with fewer, larger blocks to reduce the performance penalty, but I got sticker shock after seeing the 10%.
– Haldean Brown
Mar 21 at 18:34
My first pass at using locking came with a ~10% performance penalty; the problem is that the engine is a complex piece of code that accesses all of these collections in a bunch of different places, so I end up doing a lot of locking and unlocking. I could probably do a cleverer thing with fewer, larger blocks to reduce the performance penalty, but I got sticker shock after seeing the 10%.
– Haldean Brown
Mar 21 at 18:34
I just saw Peter's edit saying that (un)locking should be near-instantaneous, which makes me wonder if I did a dumb thing when I wrote my locking implementation..
– Haldean Brown
Mar 21 at 18:35
I just saw Peter's edit saying that (un)locking should be near-instantaneous, which makes me wonder if I did a dumb thing when I wrote my locking implementation..
– Haldean Brown
Mar 21 at 18:35
Just for your edification, try creating a simple driver class with a main method that leverages a bunch of different locking paradigms/primitives (synchronized, the lock types etc). A 10% performance penalty smells like something isn't quite right on the implementation side. Did you run your code through a profiler? Is your use case write-heavy?
– Not a JD
Mar 21 at 18:39
Just for your edification, try creating a simple driver class with a main method that leverages a bunch of different locking paradigms/primitives (synchronized, the lock types etc). A 10% performance penalty smells like something isn't quite right on the implementation side. Did you run your code through a profiler? Is your use case write-heavy?
– Not a JD
Mar 21 at 18:39
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55286705%2fis-a-java-collection-guaranteed-to-be-in-a-valid-usable-state-after-a-concurren%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
