Re: [ros-dev] Vote for a code freeze.

[Murphy, Ged (Bolton)]

Richard wrote:
> I believe it's time to do a code freeze.

+1

I've stopped working on ReactOS as it's instability is frustrating.

Ged.

[Saveliy Tretiakov]

Murphy, Ged (Bolton) пишет:
> I've stopped working on ReactOS as it's instability is frustrating.

+1
Everytime I try to work on ros it doesn't compile or boot. For example, 
now it doesn't compile. Yesterday it compiled but didn't work.
I'm not shure if code freeze will help though.

[Aleksey Bragin]

I was supposed to post a plan we worked out together with WaxDragon,  
but I was at SYSTEMS 2006 expo and also this hosting problems came -  
which made it impossible to do.

I will post a message here (most probably today) and, I'm sure, we're  
going to discuss it heavily.

WBR,
Aleksey Bragin.

On Oct 31, 2006, at 9:20 AM, Saveliy Tretiakov wrote:
> Murphy, Ged (Bolton) пишет:
> > I've stopped working on ReactOS as it's instability is frustrating.
>
> +1
> Everytime I try to work on ros it doesn't compile or boot. For  
> example,
> now it doesn't compile. Yesterday it compiled but didn't work.
> I'm not shure if code freeze will help though.

[Christian Wallukat]

Hi all,

I have a problem with CriticalSection / InterlockIncrement / Decrement on
WinXP (sorry for bother but maybe it is also important for us):

In my program I work with around 200 threads which access a list of objects
(pointer). Between the Enter and Leave the Threads delete or add an object.

Sometimes it take more than 5 seconds to enter the critical section (every
thread need for the operation around 5 ms (5 * 200 = 1000 ms -> 1 second)) I
also see that the Enter has taken 10 seconds ...

There is no load on that system (around 10 %).

After playing around with InterlockIncrement and ILDec I have implemented 
it in asm:

int MyLockInc(volatile long *lCount)
{
    //variables
    ///////////
    int nRes = 0;

__asm
    {
    	mov ecx, lCount;
    	mov eax, 1;
    	lock xadd [ECX], EAX;
    	inc EAX;
        	mov nRes, EAX;
    };

return nRes;
};

int MyLockDec(volatile long *lCount)
{
    //variables
    ///////////
    int nRes = 0;

__asm
    {
    	mov ecx, lCount;
     	mov eax, -1;
    	lock xadd [ECX], EAX;
    	dec eax;
    	mov nRes, EAX;
    };

return nRes;
};

But it is the same !!!!
What can I do ?

My problem is, that if I need more than 3 seconds for
This operation (which should be more than enough) the 
Operation will be done again (by an external tool) 
which creates ++ new Requests for each one which has 
failed (not just in time)...

You can imagine what will happen after 10 failed requests...
I cant change the behaviour of the other program ...

Please help I play around on this stupid problem since 
5 month ...

Kind regards

Christian

[Rick Parrish]

Christian Wallukat wrote:
> I have a problem with CriticalSection / InterlockIncrement / Decrement on
> WinXP (sorry for bother but maybe it is also important for us):

Try this ... add a call to Sleep(0) just before attempting to acquire 
the lock. That *may* produce better average performance.

-rick

[Christian Wallukat]

Hi Rick,

you are right, the average performance was better, but there are also
many requests which are time out ...

Do you have another idea ?
BTW: Can you explain what a Sleep(0) does ?
(Whats the background ?)

I have no clue ...
I used lock xadd...

Kind regards

Christian

-----Ursprüngliche Nachricht-----
Von: [e-mail] [mailto:[e-mail]] Im
Auftrag von Rick Parrish
Gesendet: Mittwoch, 1. November 2006 03:23
An: ReactOS Development List
Betreff: Re: [ros-dev] Mayday ... Critical Section problems

Christian Wallukat wrote:
> I have a problem with CriticalSection / InterlockIncrement / Decrement on
> WinXP (sorry for bother but maybe it is also important for us):

Try this ... add a call to Sleep(0) just before attempting to acquire 
the lock. That *may* produce better average performance.

-rick
_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev
-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.13.21/509 - Release Date: 31.10.2006

[Rick Parrish]

Christian Wallukat wrote:
> Do you have another idea ?

Maybe ...
> BTW: Can you explain what a Sleep(0) does ?

The idea is to have the thread requesting the lock to briefly yield the 
CPU (at least the remainder of the current time quantum). Some other 
thread that might already have the lock acquired gets a change to finish 
it's work and release the lock.

In your original post - you mentioned 200 threads. Are these threads all 
fighting for the same critical section?

Perhaps you could break up the main data structure into smaller pieces - 
each with it's own critical section (finer granularity of locking).

Instead of 199 threads waiting on 1 thread (that has the lock) you have 
180 threads waiting on 20 others to release some lock (but each of the 
20 is able to continue unimpeded).

-rick

[Alex Ionescu]

Rick Parrish wrote:
> Christian Wallukat wrote:
> > I have a problem with CriticalSection / InterlockIncrement / Decrement on
> > WinXP (sorry for bother but maybe it is also important for us):
>
> Try this ... add a call to Sleep(0) just before attempting to acquire 
> the lock. That *may* produce better average performance.
>
> -rick
> _______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

You should never use Sleep(0), that's a horrible suggestion.

Use Sleep(1) and/or, SwitchToThread(), and/or YieldProcessor() and /or
__mm_pause ("pause").
-- 
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS

[Rick Parrish]

Alex Ionescu wrote:
> Rick Parrish wrote:
> > Try this ... add a call to Sleep(0) just before attempting to acquire 
> > the lock. That *may* produce better average performance.
>
> You should never use Sleep(0), that's a horrible suggestion.
>
> Use Sleep(1) and/or, SwitchToThread(), and/or YieldProcessor() and /or
> __mm_pause ("pause").

Thanks Alex. I'll have to check these out.

Oh, and Timo's suggestion is very retro (but very valid) if you remember 
VAX-11 architecture.

http://h71000.www7.hp.com/DOC/73final/4515/4515pro_023.html

(wandering off topic)

-rick

[James Tabor]

Rick Parrish wrote:
> Alex Ionescu wrote:
> > Rick Parrish wrote:
> > > Try this ... add a call to Sleep(0) just before attempting to acquire 
> > > the lock. That *may* produce better average performance.
> >
> > You should never use Sleep(0), that's a horrible suggestion.
> >
> > Use Sleep(1) and/or, SwitchToThread(), and/or YieldProcessor() and /or
> > __mm_pause ("pause").
>
> Thanks Alex. I'll have to check these out.
>
> Oh, and Timo's suggestion is very retro (but very valid) if you remember 
> VAX-11 architecture.
>
> http://h71000.www7.hp.com/DOC/73final/4515/4515pro_023.html
>
> (wandering off topic)
>
> -rick

Yes, it's old school,,, sleep 0 just allows another process (thread) to run and
put the one you are running back on top of the "ready to run list". With M$ coding
it's all different now.
Thanks,
James

[Timo Kreuzer]

What about an Interlocked Singly Linked List?
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/bas...

Christian Wallukat schrieb:
> Hi all,
>
> I have a problem with CriticalSection / InterlockIncrement / Decrement on
> WinXP (sorry for bother but maybe it is also important for us):
>
> In my program I work with around 200 threads which access a list of objects
> (pointer). Between the Enter and Leave the Threads delete or add an object.
>
> Sometimes it take more than 5 seconds to enter the critical section (every
> thread need for the operation around 5 ms (5 * 200 = 1000 ms -> 1 second)) I
> also see that the Enter has taken 10 seconds ...
>
> There is no load on that system (around 10 %).
>
> [...]

[D. Hazelton]

On Tuesday 31 October 2006 03:20, Saveliy Tretiakov wrote:
> Murphy, Ged (Bolton) пишет:
> > I've stopped working on ReactOS as it's instability is frustrating.
>
> +1
> Everytime I try to work on ros it doesn't compile or boot. For example,
> now it doesn't compile. Yesterday it compiled but didn't work.
> I'm not shure if code freeze will help though.

I haven't tried a 3.0+ build, but with the 2.1 series I have had ReactOS 
running on real hardware, although it took some doing, since the disc itself 
refused to boot. This *might* be because I tend to run slightly older systems 
that have proven stability, but be that as it may, if ReactOS no longer runs 
on real hardware, then there is a problem somewhere.

(I once thought I might be able to help, but I am not used to writing C++ for 
low-level interfaces - for those I've always used C)

DRH

[Brandon Turner]

D. Hazelton wrote:
> (I once thought I might be able to help, but I am not used to writing C++ for 
> low-level interfaces - for those I've always used C)
>
> DRH

Good thing our whole kernel and system lib set is in C. ;)
-- 
Brandon Turner
~~~~~~~~~~~~~~~~~~~~~~~~
ReactOS Release Engineer
www.reactos.org
~~~~~~~~~~~~~~~~~~~~~~~~
Sharp Shell Lead Developer
http://www.codeplex.com/Wiki/View.aspx?ProjectName=SHARPSHELL

[D. Hazelton]

On Friday 03 November 2006 21:46, Brandon Turner wrote:
> D. Hazelton wrote:
> > (I once thought I might be able to help, but I am not used to writing C++
> > for low-level interfaces - for those I've always used C)
> >
> > DRH
>
> Good thing our whole kernel and system lib set is in C. ;)

When I took a cursory glance I didn't look at the core system or kernel - I 
was doing a once over of the entire code base to check general coding style 
and what stuck with me was the amount of C++ code

DRH

[Klemens Friedl]

> When I took a cursory glance I didn't look at the core system or kernel - I
> was doing a once over of the entire code base to check general coding style
> and what stuck with me was the amount of C++ code

???

The ReactOS source code (v.0.3.0, "reactos" directory) consist of:
C: 92.22%
C++: 4.69%
ASM: 1.01%

The ReactOS Kernel (v. 0.3.0) consist of:
C: 95.70%
ASM:  4.30%

The whole ReactOS trunk directory (sept. 2006; with subsys and rosapps):
C: 78.70%
C++: 5.46%
ASM: 1.41%

All percents based on the SLOC stats, which has been gathered by using
David A. Wheeler's 'SLOCCount':
http://www.reactos.org/history/10y/statistics.html