Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #4845 > unrolled thread

Scalable locks...

Back to article view | Back to comp.programming

Contents

  Scalable locks... Ramine <ramine@1.1> - 2014-10-21 18:10 -0700
    Re: Scalable locks... Ramine <ramine@1.1> - 2014-10-21 18:39 -0700
      Re: Scalable locks... Richard Heathfield <invalid@see.sig.invalid> - 2014-10-22 00:12 +0100
        Re: Scalable locks... Ramine <ramine@1.1> - 2014-10-23 11:39 -0700
          Re: Scalable locks... Richard Heathfield <invalid@see.sig.invalid> - 2014-10-23 16:59 +0100
            Re: Scalable locks... Ramine <ramine@1.1> - 2014-10-23 12:05 -0700
            Re: Scalable locks... Kaz Kylheku <kaz@kylheku.com> - 2014-10-23 18:02 +0000
              Re: Scalable locks... Richard Heathfield <invalid@see.sig.invalid> - 2014-10-23 22:01 +0100

#4845 — Scalable locks...

Hello,


Please read the following paper to know why i have invented my
scalable MLock:


http://pdos.csail.mit.edu/papers/linux:lock.pdf


But you have to be carefull, the Ticket spinlock with a proportional
backoff is not good, cause if there is more context switch the thread
that is scheduled has to use all its quantum time and this will slow
a lot the Ticket spinlock with a proportional backoff , so you have
to use a Sleep(0) just after the proportional backoff to solve this 
problem, but i have benchmarked it by adding the sleep(0) and i have 
noticed that my scalable MLock will give better performance than
the Ticket spinlock with a proportional backoff and with a sleep(0)
just after the proportional backoff, so i advice you to use my scalable 
MLock instead cause it's faster and better.


You can download my scalable MLock from:

https://sites.google.com/site/aminer68/


Thank you,
Amine Moulay Ramdane.

[toc] | [next] | [standalone]

#4846

The Sleep(0) is on Windows, to give up he time slice.


On 10/21/2014 6:10 PM, Ramine wrote:
> Hello,
>
>
> Please read the following paper to know why i have invented my
> scalable MLock:
>
>
> http://pdos.csail.mit.edu/papers/linux:lock.pdf
>
>
> But you have to be carefull, the Ticket spinlock with a proportional
> backoff is not good, cause if there is more context switch the thread
> that is scheduled has to use all its quantum time and this will slow
> a lot the Ticket spinlock with a proportional backoff , so you have
> to use a Sleep(0) just after the proportional backoff to solve this
> problem, but i have benchmarked it by adding the sleep(0) and i have
> noticed that my scalable MLock will give better performance than
> the Ticket spinlock with a proportional backoff and with a sleep(0)
> just after the proportional backoff, so i advice you to use my scalable
> MLock instead cause it's faster and better.
>
>
> You can download my scalable MLock from:
>
> https://sites.google.com/site/aminer68/
>
>
> Thank you,
> Amine Moulay Ramdane.
>
>
>
>

[toc] | [prev] | [next] | [standalone]

#4847

Ramine wrote:

> 
> 
> The Sleep(0) is on Windows, to give up he time slice.

That's only necessary if you're running Win9x, and even then only if you've 
got a 16-bit application. I suggest you upgrade to a decent operating system 
(or, if you prefer, Windows 7).

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#4853

On 10/21/2014 4:12 PM, Richard Heathfield wrote:
> Ramine wrote:
>
>>
>>
>> The Sleep(0) is on Windows, to give up he time slice.
>
> That's only necessary if you're running Win9x, and even then only if you've
> got a 16-bit application. I suggest you upgrade to a decent operating system
> (or, if you prefer, Windows 7).
>



The problem shows on Windows 2008 server too, so i had
to use sleep(0) to correct the problem.



Amine Moulay Ramdane.

[toc] | [prev] | [next] | [standalone]

#4854

Ramine wrote:

> On 10/21/2014 4:12 PM, Richard Heathfield wrote:
>> Ramine wrote:
>>
>>> The Sleep(0) is on Windows, to give up he time slice.
>>
>> That's only necessary if you're running Win9x, and even then only if
>> you've got a 16-bit application. I suggest you upgrade to a decent
>> operating system (or, if you prefer, Windows 7).
> 
> The problem shows on Windows 2008 server too, so i had
> to use sleep(0) to correct the problem.

Is it your claim, then, that Windows 2008 server uses co-operative 
multitasking rather than pre-emptive?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#4855

On 10/23/2014 8:59 AM, Richard Heathfield wrote:
> Ramine wrote:
>
>> On 10/21/2014 4:12 PM, Richard Heathfield wrote:
>>> Ramine wrote:
>>>
>>>> The Sleep(0) is on Windows, to give up he time slice.
>>>
>>> That's only necessary if you're running Win9x, and even then only if
>>> you've got a 16-bit application. I suggest you upgrade to a decent
>>> operating system (or, if you prefer, Windows 7).
>>
>> The problem shows on Windows 2008 server too, so i had
>> to use sleep(0) to correct the problem.
>
> Is it your claim, then, that Windows 2008 server uses co-operative
> multitasking rather than pre-emptive?
>

the problem shows on pre-emptive operating system like Windows 2008 
server, i have explained to you why, and i have used sleep(0) and
it has worked correctly.




Amine Moulay Ramdane.

[toc] | [prev] | [next] | [standalone]

#4858

On 2014-10-23, Richard Heathfield <invalid@see.sig.invalid> wrote:
> Ramine wrote:
>
>> On 10/21/2014 4:12 PM, Richard Heathfield wrote:
>>> Ramine wrote:
>>>
>>>> The Sleep(0) is on Windows, to give up he time slice.
>>>
>>> That's only necessary if you're running Win9x, and even then only if
>>> you've got a 16-bit application. I suggest you upgrade to a decent
>>> operating system (or, if you prefer, Windows 7).
>> 
>> The problem shows on Windows 2008 server too, so i had
>> to use sleep(0) to correct the problem.
>
> Is it your claim, then, that Windows 2008 server uses co-operative 
> multitasking rather than pre-emptive?

If Ramine believed that Windows 2008 is cooperative, he would not
use the terminology "give up the time slice", which is not applicable
to cooperative tasking.

If you're tuning the implementation of some locking primitives, you sometimes
need a way to give up a time slice.

Ramine appears to be relying on a documented behavior of Sleep in MSDN:

  "A value of zero causes the thread to relinquish the remainder of its time
  slice to any other thread that is ready to run. If there are no other threads
  ready to run, the function returns immediately, and the thread continues
  execution."

Threading primitives on GNU/Linux also used to do the equivalent of Sleep(0) in
their spin-locking loops, until futexes were invented.

If you don't have futexes, and no existing suspension primtive such as a
semaphore is appropriate to your locking algorithm, you may have to rely
on a crude "give up timeslice" operation to avoid burning cycles.

OTOH if you see Sleep(0) in application code, then that is usually a sign that
the developers have run into thread-related situations in the code which they
are trying to band-aid, without knowing entirely what they are doing.

[toc] | [prev] | [next] | [standalone]

#4860

Kaz Kylheku wrote:

<snip>
 
> Ramine appears to be relying on a documented behavior of Sleep in MSDN:

Thanks, Kaz. Mea culpa and all that. I apologise to Ramine for the 
unwarranted criticism.

<snip>

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web