Thread Safety about cparse

[VinGarcia]

Uhm, so what you have is multiple threads writing to the same TokenMap or PackToken at the same time. So I can try to think of some alternatives, but I might need more info to understand which options we have.

One possible option might be to just change the architecture of the project so that threads communicate using a safe channel, as in "passing messages" instead of "sharing variables", but this depends on the specific problem.

A strategy that I love to use in other languages is the BlockingQueue strategy, where you only send messages from one thread to the other using these queues, if the queue has a max limit and it is full the thread sleeps. Then on the other side if a thread tries to read from the queue and it is empty it sleeps, otherwise, it just gets the data and continues.

You could for example create a new "channel" or "blocking_queue" type in your language and use it for synchronization:

• https://github.com/cparse/cparse/wiki/Defining-New-Types

This strategy would allow you to keep the packTokens as fast as they normally are and only pay for the extra synchronization price when using the channels.

However, after a quick search, it doesn't look like we have a standard implementation of that concept available neither on the std library nor on boost =/. But we still have some code snippets online that might be useful if you are willing to implement that on your own code:

• https://stackoverflow.com/questions/9396279/consumer-producer-in-c/9396587#9396587
• https://stackoverflow.com/questions/12805041/c-equivalent-to-javas-blockingqueue

[VinGarcia]

If this solved your problem I will close this issue (no hurry though)

[sarthaku21]

Hi,
I have introduced a recursive lock in packToken that ensures safe access. The problem is when we try to run calculator in a parallel thread. The = operation in packToken does a delete base, which cause the calculator to give a segmentation fault when resolving refTokens. I am still not able to solve this efficiently.
The application contains multiple threads, some updating packTokens, other evaluating expressions using calculator to do some tasks.
I am using the tokenMap as a shared memory between these threads to communicate. I will go ahead and limit access when calculator is doing it's job. But, I think it can be done more efficiently.
Thanks.

[VinGarcia]

Yeah, so this is just my opinion, but I really think that adding a lock on every packToken might be the wrong approach. For example, I don't think there is any programming language that has built-in locks for every variable exactly because this is very inefficient.

So if efficiency is a concern I would recommend either using explicit locks, which are already available in C++ and should be easier to add to the library than the current approach, or trying some other strategy like the channels I mentioned.

Another interesting strategy is to use immutable structures whenever you can, which is the strategy used by the Elixir programming language for preventing this type of problem.

About the operator=, since you are already forking the library you could try to update the delete method of each type to prevent this segmentation fault. But as I said, this might be complicated.