CODEWITHSUNDEEP
c++zeromq
q0987
q0987

Reputation: 35992

Implement multi-thread applications without locks in ZeroMQ

http://www.zeromq.org/blog:multithreading-magic

The message-based ZeroMQ framework implements concurrent/multi-thread applications without using locks.

Question> how does it actually works for the following example?

For example:

We have two clients each read data from the same database and then later put back modified results.

ClientA: Read data A, modified A.value = A.value + 1 then write data A back to database
ClientB: Read data A, modified A.value = A.value + 2 then write data A back to database

Question> I am not able to figure out how to implement such a system with ZeroMQ so that I don't need locks to control the behaviors of ClientA and ClientB. How can it prevent the following case from happening.

ClientA read data A first
ClientB read data A second
ClientB write data A back // now data.value has been increased by two
ClientA write data A back // now the conflict! because the original value of A has been 
                          // modified by ClientB and ClientA has no information about it.
                          // If ClientA writes the A back without knowing the update A
                          // then the changes made by ClientB will be voided.

How does ZeroMq address such an issue without using locks by using its messages?

Thank you

Upvotes: 3

Views: 1246

Answers (2)

flup
flup

Reputation: 27103

ZeroMQ offers you a toolbox which enables you to solve this problem, but the best solution very much depends on the details.

For instance, if the clients hammer the server with updates, but the client's only intent is to increment A, it could simply send a message containing the value by which to increment to the server, without knowing the exact value of A.

More generally, the server could publish updates to the clients, and the clients could request that the server update the value of A, as in the clustered hashmap protocol. This protocol however, as far as I can see, does not detect concurrent updates to the same key. You could modify it to add optimistic locking or try and build something on top of the protocol. The sample implementation has the server doing the updates in a single thread and numbers the updates, so you could use that sequence number. But it would still take some effort.

For more detail on the protocol, see the ZeroMQ guide

Upvotes: 1

yiding
yiding

Reputation: 3590

A simple answer is that you can emulate a lock with a concurrent queue.

Say you have a queue of size 1 that's filled. Clients will try to grab a value from the queue. The one that succeeded will perform the operation and put a value back in the queue. The one that failed would go to sleep, and proceed after the successful client finished.

This is arguably something of an academic example. In reality you would probably be using transactions in your database system instead of locks amongst your clients.

Upvotes: 1

Related Questions