Good day to all!
There is a library binary of some computational functions written in an assembler, there are no source codes, as a result, there is also no deep understanding of the internals of these functions. There is the following theoretical question: is it possible to safely use these functions in a multi-threaded application? I understand that you can "restrict" all calls from this library to mutexes, but there is no certainty that they will not conflict with other functions of the application, for example, with malloc (). Solve my doubts pliz.

  • one
    @margosh, I do not think that computational functions may conflict with malloc (or something similar). Using mutexes seems like a reasonable security measure. Only here it is necessary to see if there are any "pair" calls in the library (such as open / close). In such a case, you may have to "lock" the entire chain. It is hardly worth it to refine and pull out these calculations into a separate process (it will not work quickly). - avp
  • @avp, yes, it will not work as a separate process in this case. I can’t see what’s inside, there’s nothing but a binary. I imagine that most of the assembly code is reduced to working with registers, and there should not be conflicts with non-library functions, but can this code be translated into some kind of system call that is not designed for multi-threaded use? - margosh

3 answers 3

In general, such a library can cost you sleepless nights spent on debugging. I do not recommend to use. If I understand anything at all, then even critical sections will not really help. It depends on whether a separate copy of the library is created for each stream. I personally believe that no. And if so, then some tricky f-tion, modifying the internal variables of the library and tied to their values, caused several times from different threads, completely violate the logic of the library.

  • four
    Gold words. I also want to remind the old wisdom of mushroom pickers: If you don’t know a mushroom, don’t take it. - skegg
  • @mikillskegg, in the subject =) - Salivan

There is the following theoretical question: is it possible to safely use these functions in a multi-threaded application?

The probability, of course, is. But I'm afraid they are less than 100%

  • I suspect so ... I wanted to know the opinions. - margosh

If you mean that for some sections of the application there is no simultaneous, parallel access, then you can use such a tool as critical sections . Critical sections are objects used to block access of all threads (threads) of an application, except one, to some important data at one time. They will secure the program from simultaneous access to some of its sections of code. The tool is extremely easy to use.

See EnterCriticalSection Function

  • The idea is correct, but the question is not about that. Also seen the tag "unix"? - skegg
  • @mikillskegg, oh, yes, exactly, Unix is ​​.... something, as I saw the label "Assembler", for some reason I immediately thought that it was Windows. In that case, I apologize for the mistake ... - Salivan
  • @mikillskegg Well, there are critical sections everywhere. Challenges others. The only question is where to put them. If for each function call (and they are computational), it will be correct, but not fast. Otherwise - how it goes. - alexlz
  • @alexz, the problem is not only in speed, but primarily in that it is not known which pieces of code need to be cracked additionally, since it is not known what is used inside the library, there is an example at the end of the question. - margosh
  • @margosh Or I didn’t understand something, or ... If this compote will also conflict with malloc, then no mutexes will help. What I wrote above is essentially single-threaded work, in no case can two threads simultaneously call a function from the library. - alexlz