My problem is: I have class: I need to add new characters to StringBuilder concurrently and atomically. But problem is, only last 128 characters should be in this object. I can’t use StringBuffer, because operation should be non-blocking. So,there are two operations: First: check if StringBuilder already has 128 chars. Second: if it has not -> add new char, if
Tag: concurrency
How to fix the Issue with replacing AsyncTask to connect socket?
I’m trying to use This approach(Marked Answer) to replace my code with AsyncTask to make connection between user in android and server, And here’s what I’ve done : Note: I’m not using any specific pattern, just trying to achieve this goal on a basic structure. MainActivity : ClientConnection : ConnectionTask : ConnectionRunningTask: So base on the above code I’ll try
Thread join(1) usage in mutlithread wait-notify example in Java
I have example with wait-notify application which is invoked from main: } and invoker } As I expected “exception” message should be printed as I join(1) to threads and wait them to die only 1 mills, but they are sleeping more than that. What am I missing? Answer join(1) has 3 ways ‘out’: The thread you called join on ends,
Why does Thread.activeCount() count more threads than my code creates?
I’m a beginner in Java development and i trying to write a multi threading process with using CountDownLatch in below code. But ExecutorService not working as it should. ExecutorService thread number not working as it defined in code. Console log; I defined thread number as 50, but when it works Thread.activeCount() function returns 81. Why ? Answer You are using
What does “Aren’t allocating the things put into queues” mean?
I’m reading this: https://concurrency.markmail.org/search/?q=ArrayBlockingQueue+LinkedBlockingQueue#query:ArrayBlockingQueue%20LinkedBlockingQueue%20from%3A%22Doug%20Lea%22+page:1+mid:sgx3amdfga7esqul+state:results In which Doug Lea says: Usually, when you are putting something into a queue, you will have just allocated that new something. And similarly, when you take something out you usually use it and then let it become garbage. In which case the extra allocation for a queue node is not going to make much difference
Why does calling CompletableFuture::cancel cause an immediate CancellationException
I am trying to call cancel on CompletableFuture. It seems from the docs: If not already completed, completes this CompletableFuture with a CancellationException. Dependent CompletableFutures that have not already completed will also complete exceptionally, with a CompletionException caused by this CancellationException. That it should complete them exceptionally which is what I was expecting but instead, it throws and immediate CancellationException.
Is this the correct way to extract counts from a Concurrent Hash Map without missing some or double counting?
Working on something where I’m trying to count the number of times something is happening. Instead of spamming the database with millions of calls, I’m trying to sum the updates in-memory and then dumping the results into the database once per second (so like turning 10 +1s into a single +10) I’ve noticed some strange inconsistency with the counts (like
If a method is synchronized, do the called methods also have to be synchronized?
If a method is synchronized, do the called methods also have to be synchronized? What is correct in the following example? Answer If a method is synchronized, do the called methods also have to be synchronized? No. There is no general reason that you need to call a synchronized method from another synchronized method. Assuming that the methods are synchronizing
Why do we need the volatile keyword when the core cache synchronization is done on the hardware level?
So I’m currently listing to this talk. At minute 28:50 the following statement is made: „the fact that on the hardware it could be in main memory, in multiple level 3 caches, in four level 2 caches […] is not your problem. That’s the problem for the hardware designers.“ Yet, in java we have to declare a boolean stopping a
Why is volatile keyword not needed for inter-thread visibility when one of the threads involved is the main() thread?
Consider the following program: Here the stopRequested is not declared as volatile – so ideally the thread backgroupdThread must not stop – and execute endlessly But when running this locally – the thread backgroundThread is gracefully shutting down with the message: “Stopping the thread!!”. Are all the updates by the main() thread to the shared variable stopRequested visible to the