1

Closed

Thread-safe version

description

Hello.

First of all, thank you for making this implementation public. It will be very useful for a lot of researchers.

So, my questions are:
  1. Are you planning to build a thread-safe version?
  2. .Does all the "non thread-safeness" of the scheme come from the BigPolyArith class? I mean, if this one were thread safe, then all the others would be so as well or are there other issues?
Cordially.
Closed Jun 19, 2016 at 7:47 PM by kimlaine

comments

kimlaine wrote Jan 20, 2016 at 6:50 AM

Hello,

Here is some explanation:

2. Currently the main problem is with the MemoryPool, which is not thread-safe for efficiency reasons, and is used by basically everything (Encryptor, Evaluator, etc. create each their own MemoryPool). Moreover, even if MemoryPool was thread-safe, mutating BigPolys and BigUInts wouldn't be, and I don't know of any reasonable solution to that. The BigPolyArith class is in fact not used by any other parts of the library. It's there simply to help users manipulate BigPolys.

1. I would love to have a thread-safe version of MemoryPool. The effects on performance are not clear to me, but there is a good chance that using e.g. one global MemoryPool for everything might actually speed things up. The reason we don't have this yet is that it takes quite a lot of work to do, and currently much of the things that one might want to achieve with multithreading can already be done by simply creating a new Encryptor, Encoder, etc. in each thread, although admittedly this is annoying.


Kim