The threads parameter is unused in Corosync 2.0. In corosync 1.y, there was threading used throughout the code base. It resulted in race conditions and incorrect behavior, so threading was compeltely removed in 2.0.
Threads are an anti-pattern and evil, and should never be used in proper software IMNSHO :)
Regards
-steve
On Wed, Jun 3, 2015 at 7:02 AM, Ulrich Windl <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx> wrote:
>>> Jan Friesse <jfriesse@xxxxxxxxxx> schrieb am 03.06.2015 um 13:49 in Nachricht
<556EE9B1.7080501@xxxxxxxxxx>:
> Ulrich Windl napsal(a):
>> Hi!
Hi!
>>
>> I have a question on the "threads" parameter (How many threads should be
> used to encypt and sending message):
>>
>> How can encryption of one message be distributed to multiple threads? If
> there are multiple messages to be created and sent sequentially, how would
> the use of multiple threads to encrypt them improve the situation.
>>
>> Is the code really free of race conditions?
>
> Nobody knows (how can that be proved?
Assuming mutual exclusion primitives (on the hardware) work OK, you can do that by careful design I guess.
> Because if you can prove it, go
> ahead for Nobel prize), but it's for sure not very common (= almost
> nobody use that) code path, so I would say probably no (that's why
> corosync 2.x doesn't have threads at all).
You are not going into details with the design (my question), but I guess if you allocate some memory under mutual exclusion from a shared pool, and each thread only works on that allocated memory, there should not be any race condition.
So whats' the use of a threads parameter if corosync does not use threads???
Ulrich
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
_______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
