From: aminer on

I wrote:
> If [2] AND [5] THEN you have a deadlock
> and
> the possibility of Lock-convoy
> and bad scalability.
>
> If [6] THEN you have a bad scalability problem.


If - your threads (or processes) are using
the same critical sections and - you didn't follow [2]
AND
you are using a critical section or spinlock and
there is a high contention on them [5]
THEN you have a deadlock
and
the possibility of Lock-convoy
and bad scalability.

If [6] THEN you have a bad scalability problem.

etc.


Sincerely,
Amine Moulay Ramdane.



On Apr 4, 1:17 am, aminer <ami...(a)videotron.ca> wrote:
> Hello,
>
> I have stated the following theorems and rules:
>
> [1] IF your algorithm exhibit much more data parallelism THEN
> it will be much more efficient.
>
> [2] IF two or more processes or threads use the same critical
> sections THEN they - the processes or threads - must take
> them in the same order to avoid deadlock - in the system - .
>
> [3] If there is LESS contention THEN the algorithm will
> scale better. Due to the fact that S (the serial part)
> become smaller with less contention , and as N become bigger,
> the result - the speed of the program/algorithm... - of the
> Amdahl's equation 1/(S+(P/N)) become bigger.
>
> [4] You have latency and bandwidth , so, IF you use efficiently
> one or both of them - latency and bandwidth - THEN your algorithm
> will be more efficient.
>
> [5] IF you are using a critical section or spinlock and there is
> a high contention- with many threads - on them THEN there is a
> possibility of a Lock convoy. Due to the fact that the thread
> entering the spinlock or critical section may context switch
> and this will add to the service time - and to the S (serial part)
> of the Amdahl's equation - and this will higher the contention and
> create a possibility of a Lock convoy and to a bad scalability.
>
> We can elevate the problem in [5] by using a Mutex or a Semaphore
> around the crital section or the spinlock...
>
> [6] If there is contention on a lock - a critical section ... -
> and inside the locked sections you are the I/O - example
> logging a message to a file - this will lead the calling thread
> to block on the I/O and the operating system will deschedule
> the blocked thread until the I/O completes, thus this situation
> will lead to more context switching, and therefore to an increased
> service time , and longer service times, in this case, means
> more lock contention, and more lock contention means a bad
> scalability.
>
> etc.
>
> So , and as in logic , you can reason by deduction like this:
>
> If [1] AND [3] THEN your algorithm is much more efficient.
>
> If [2] AND [5] THEN you have a deadlock
> and
> the possibility of Lock-convoy
> and bad scalability.
>
> If [6] THEN you have a bad scalability problem.
>
> etc.
>
> IF you follow and base your reasonning on those theorems
> - or laws or true propositions or good patterns - like rules or
> theorems [1] , [2] , [3], [4] , [5], [6]... - THEN your will
> construct
> a model that will be much more CORRECT and EFFICIENT.
>
> And it is one of my preferred methodology in programming.
>
> I will try to add more of those rules , theorems , laws...
> next time...
>
> Sincerely,
> Amine Moulay Ramdane.


From: aminer on

I wrote:
> IF - your threads (or processes) are using
> the same critical sections and - you didn't follow [2]
> AND
> you are using a critical section or spinlock and
> there is a high contention on them [5]
> THEN (you have a deadlock
> and
> the possibility of Lock-convoy
> and bad scalability.)
>
> If [6] THEN you have a bad scalability problem.
>
> etc.


And, as in logic, you can reason by deduction - inference -

:)


Sincerely,
Amine Moulay Ramdane.