According to these answers, when several heterogeneous results (say {MTensor, mint, double}) are needed to be returned from a LibraryLink computation(), the way to go is to store the results in some global library state, and then retrieve every field MTensor, mint, double with a new dedicated function like retrieve_array_from_computation(), retrieve_int_from_computation() and retrieve_real_from_computation().

Does this imply that some {MTensor, mint, double} struct must be kept in some global state within the library?
If yes, should I worry about possible concurrent access, e.g. if the Mathematica user is calling into computation() from a ParallelTable or so?

In this case I should store not only a {MTensor, mint, double} in the global state, but a whole random-access collection of such objects protected by a mutex. And computation() should return some index into the collection, that the caller in a thread must use in order not to retrieve the results computed in another thread.

While I'm okay with doing all this, I'm not confident it's truly needed because I'm not sure what's the memory model for parallelism with LibraryLink. Will library global space be actually shared among threads, or will each kernel run its own independent version of the loaded library?

  • 3
    $\begingroup$ Mathematica does parallelization by running multiple, separate processes that do not share memory. Mathematica does not support shared-memory parallelization. $\endgroup$
    – Szabolcs
    Jun 13 '21 at 20:52
  • $\begingroup$ @Szabolcs Oh, so you mean that I do not need be worried about synchronizing access to the global mutable state? Every parallel worker will have its own copy of my lib singleton(s) :) That's good news. Thanks! $\endgroup$
    – iago-lito
    Jun 13 '21 at 20:56
  • 1
    $\begingroup$ For returning multiple results, do take a look at this: mathematica.stackexchange.com/a/247056/12 $\endgroup$
    – Szabolcs
    Jun 14 '21 at 8:09
  • 1
    $\begingroup$ @Szabolcs Wow, that sounds awesome, thank you :D I'm curious (and a bit afraid) why DataStores are not documented.. why is that? Does this imply that they have no stability guarantee ? $\endgroup$
    – iago-lito
    Jun 14 '21 at 9:20
  • 1
    $\begingroup$ @iago-lito DataStore is not documented because it's API has been added to LibraryLink relatively recently and more effort at Wolfram is now directed towards finishing the new compiler which is supposed to completely alleviate the need to use LibraryLink. As for the no stability guarantee - that is correct. $\endgroup$
    – rafalc
    Jun 14 '21 at 19:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.