Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Document locking in multithreading environment [closed]

We have an application that supports binary plugins (dynamically loaded libraries) as well as a number of plugins for this application. The application is itself multithreaded and the plugins may also start threads. There's a lot of locking going on to keep data structures consistent.

One major problem is that sometimes locks are held across calls from the application into a plugin. This is problematic because the plugin code might want to call back into the application, producing a deadlock. This problem is aggravated by the fact that different teams work on the base application and the plugins.

The question is: Is there a "standard" or at least widely used way of documenting locking schemes apart from writing tons of plain text?

like image 678
arne Avatar asked Feb 15 '23 09:02

arne


1 Answers

It is a theorical approach, I hope it will help you a little.

To me you can avoid this situation by redesigning the way plugins and your application are communicating (if possible).

A plugin's code is not secure. To ensure the application's flexibility and its stability you must build a standard way to exchange informations and make critical actions with plugins.

The easiest way is to avoid to manage each specific plugin behavior by defining a lock free api. To do that you can make the critical parts of your plugins asynchronous by using ring buffer / disruptor or just an action buffer.

EDIT

Sorry if I argue again in the same way, but this seems to me to be like an "IO" problem.

You have concurrent access on some resources (memory/disc/network .... don't know which ones) and the need to expose them with high availability. And finally these resources cannot be access randomly without locking your application.

With a manager dedicated on the critical parts, the wait can be short enough to be imperceptible.

However this is not easily applicable to an already existing application, mostly if it is a large one.

if you don't already know this kind of stuff, I encourage you to look to the "disruptor". To me it is one of the modern basic to consider every time I work with threads.

like image 127
Mirette Avatar answered Feb 23 '23 21:02

Mirette