Java concurrency

Question

I am working to solve interesting concurrent problem! Not sure if I understand it correctly since I am little bit confused.

The system needs to process the prices, and typically they cannot be processed as quickly as they arrive, so the implementation must sample the latest price. The external system produces prices for several entities, interleaved into a single sequence of the form:

EntityA: pa1,      pa2,          pa3...
EntityB:      pb1,      pb2, pb3 ...
       Time ▶ ▶ ▶

For example, if during the time taken to process price pa1 the prices pa2, pa3, and pa4 arrive, the next price the application should process is pa4 and all previous prices should be ignored. Prices for other entities (e.g. pb1) do not affect the latest price entity for a, but are processed independently in the same way with respect to entity b.

For thread-safety I wanted to use ConcurrentMap

ConcurrentHashMap<String, BigDecimal> concurrentHashMap = new ConcurrentHashMap<String, BigDecimal>();

public BigDecimal getPrice(String id){
    return concurrentHashMap.get(id);
} 

public void updatePrice(String id, BigDecimal newPrice){
    concurrentHashMap.put(id, newPrice);
}

1. Will it guarantee a thread safe read/write?
2. If I write to key "a" will it lock the whole Map or writes to "b" key is available?
3. What does take following part of the task means? If during the time taken to process price Pa1 the prices Pa2, Pa3, and Pa4 arrive, then the next price the application should process is Pa4 and all previous prices should be ignored. - Probably I am overcomplicating things but does that mean I should not store and cancel price update if new more recent price arrive? If yes, then how would implementation look like?

Answer 1

From the documentation of ConcurrentHashMap:

However, even though all operations are thread-safe, retrieval operations do not entail locking, and there is not any support for locking the entire table in a way that prevents all access.

To answer your first two questions:

1. ConcurrentHashMap is guaranteed to be thread safe.

2. When writing, more than one write can happen at a time. From the documentation:

The allowed concurrency among update operations is guided by the optional concurrencyLevel constructor argument (default 16), which is used as a hint for internal sizing. The table is internally partitioned to try to permit the indicated number of concurrent updates without contention.

This means that having a concurrencyLevel of 1 will mean you can only do one write at a time. Having a concurrencyLevel of 16 means that up to 16 writes can happen at the same time.

Finally:

3.What does take following part of the task means? If during the time taken to process price Pa1 the prices Pa2, Pa3, and Pa4 arrive, then the next price the application should process is Pa4 and all previous prices should be ignored.

Here's my interpretation: You start by processing a price, in this case Pa1. At the end of processing Pa1, you're looking to process the next price. While processing Pa1, you received Pa2, Pa3, and Pa4. When selecting the next price to process, you should ignore Pa2 and Pa3 because they're old, and only process Pa4.

This seems like a homework problem so I don't want to just outright give a solution, but you need to devise a way where, you only process the most recent price you've received. You can do this by using a single variable priceToProcess which is updated whenever you receive a new price, or you could use a Queue and fill it with received prices(the last in the queue will be the one you process), etc. There's definitely more than one way to accomplish this part.

Perhaps one point of confusion is the idea of processing a price - you don't necessarily process a price just because you received it. You only process a price when you are not processing another price and there are no newer prices to process.