Bloomberg LP Interview Question
Financial Software DevelopersCountry: United States
Interview Type: Phone Interview
we could use multiversion concurrency control. when writing a key, each thread write its own version with a timestamp. when reading a key, we try to find the latest value.
if you were able to implement linda in the shared space then.this would work as the reading process would only read the data but cannot edit it in the tuple space.thread which need to write will take the take the tuple from tuple space and update the tuple and place it back in tuple space.if mean while some thread which need the that variable or data will be blocked.
For the people who are saying to copy the data before writing (using immutable objects), that only solves dirty reads. It doesn't solve multiple, concurrent writers, because the copy, update, pointer replacement operation is not atomic, so during that process, before the pointer is updated, another thread might start its own copy operation in order to write.
Yes, and there should be a atomic compare-and-swap operation to solve the concurrent writes issue
Saying that there should be an atomic compare and swap operation doesn't help with actually having one.
The atomic update doesn't solve the problem of needing to:
- read the value as an input into calculating a new value,
- doing the calculation itself.
Only then can the atomic pointer update take place. In the meantime, other threads can be reading the memory, as an input, that will soon be out of date.
So, while it is possible to do what's being asked for some class of problems, it's not possible for anything that relies an order of execution.
Of course, with literally unlimited memory, if there's also unlimited processing power, then anything is possible, by using predictive execution.
I think we can achieve this using volatile keyword for shared data. It instructs thread to maintain a local copy of shared data and threads can run concurrently with independent copy of data.
Is that even possible? Locking is to prevent overwriting state. So even if memory is unlimited we,d still need to lock access to any shared state.
I agree with sameer. Threads work with shared memory, the locking mechanism is used to prevent threads from simultaneous access to the critical section in the program, so having unlimited memory not solve concurrency issues.
I Think it may not be possible, as lock are used for consistency and improve the system performance from loss of data.
If there is unlimited memory also If anyone try to edit the data which is used by some one in the system. This may led to incosistency in the state and system may crash some time.
I'm not exactly sure what they're asking, but what if the threads don't operate directly on the same memory? Then maybe you could have some sort of inter-thread message passing instead to communicate between threads.
- jvo February 06, 2013