efficiency of spin locks vs. eresource

Hello,

This question might sound a bit off… but I am just wondering…

Consider that I have a simple linked list which is being accessed by alot of
threads. I need to synchronize this list between threads and I am wondering
if it would be better to use a spin lock to lock the list when accessing it
in general or use ERESOURCE to lock it exclusively when items are
added/removed and lock it shared when doing ptr = ptr->next_ptr.

I guess I am just wondering if in this context it is expensive (or makes
sence) to use ERESOURCE… I am aware that spin locks operate by raising
IRQL which basically makes them extermely efficient in general… On the
other hand having shared access to the data would allow multiple threads
traverse the data in parallel.

I’d appreciate to hear what you think.

Thanks,

Anton S. Yemelyanov


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

If Data structure is using only 1 Driver then better to use ERESOURCE. If
Data structure is accessing from Different Drivers u must use Spin lock.

Regards,
Satish K.S

This question might sound a bit off… but I am just wondering…

Consider that I have a simple linked list which is being accessed by alot
of
threads. I need to synchronize this list between threads and I am
wondering
if it would be better to use a spin lock to lock the list when accessing
it
in general or use ERESOURCE to lock it exclusively when items are
added/removed and lock it shared when doing ptr = ptr->next_ptr.

I guess I am just wondering if in this context it is expensive (or makes
sence) to use ERESOURCE… I am aware that spin locks operate by raising
IRQL which basically makes them extermely efficient in general… On the
other hand having shared access to the data would allow multiple threads
traverse the data in parallel.

I’d appreciate to hear what you think.

Thanks,

Anton S. Yemelyanov


You are currently subscribed to ntfsd as: xxxxx@aalayance.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Anton,

There are a thousand and one ways of locking your list, depending on what you are doing to it.

Simplicity says have one lock, and lock the whole list in unshared mode.

Having a shared lock for read, and an unshared lock for write, may well work if most of your accesses are for reading, *and the list is usually unlocked*. There is a risk, however, that if the list is usually locked for read then a writer will never get the lock. (I won’t be surprised if someone has comments on this - I haven’t studied the shared locking mechanisms in detail)

The most complex system is to have a lock for each entry on your list. When traversing the list you lock (shared) each item before going to the next one; when you are inserting an item you lock (unshared) the item before and after the place you wish to insert, and when deleting you lock the item to be deleted and the items each side. This is good for things like file control blocks where the operations are slow compared to the lock process - most of the list is unlocked most of the time, but individual items can be held for long periods. You may even find it worth having two locks on each item - a lock for modifying the item, and a lock for the list links.

All this, and I haven’t even touched what kind of lock to use…

Andy


Get your free email from AltaVista at http://altavista.iname.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

This is incorrect. The only way I can read out what you are saying is
that you believe that raising to DPC provides automatic inter-driver
synchronization. If this is the case, get thee a multi-processor machine
as quickly as possible. DPC is *per-processor*. Two threads can hold two
different spinlocks simultaneously.

So, you have to share a way of naming the same synchronization object.

So, you can use either.

ERESOURCES’s along with most every executive synchronization object
involve acquiring the dispatcher spinlock on each acquire/release. Your
decision is related more to how long you plan to be within the lock and
whether you actually can use the shared acquire mode of an ERESOURCE. If
you won’t, don’t even think about using them - just use a
mutex/spinlock.

If this is a simple push/pop list of workitems, consider using SLISTs.

ExInitializeSListHead
ExInterlockedPopEntrySList
ExInterlockedPushEntrySList

… which only take a spinlock for legacy systems which did not have the
interlock instructions. No modern chip lacks them, and this is all lock
free.

-----Original Message-----
From: Satish [mailto:xxxxx@aalayance.com]
Sent: Monday, March 05, 2001 9:07 PM
To: File Systems Developers
Subject: [ntfsd] Re: efficiency of spin locks vs. eresource

If Data structure is using only 1 Driver then better to use ERESOURCE.
If
Data structure is accessing from Different Drivers u must use Spin lock.

Regards,
Satish K.S

This question might sound a bit off… but I am just wondering…

Consider that I have a simple linked list which is being accessed by
alot
of
threads. I need to synchronize this list between threads and I am
wondering
if it would be better to use a spin lock to lock the list when
accessing
it
in general or use ERESOURCE to lock it exclusively when items are
added/removed and lock it shared when doing ptr = ptr->next_ptr.

I guess I am just wondering if in this context it is expensive (or
makes
sence) to use ERESOURCE… I am aware that spin locks operate by
raising
IRQL which basically makes them extermely efficient in general… On
the
other hand having shared access to the data would allow multiple
threads
traverse the data in parallel.

I’d appreciate to hear what you think.

Thanks,

Anton S. Yemelyanov


You are currently subscribed to ntfsd as: xxxxx@aalayance.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@exchange.microsoft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

I agree with everything danlo said, right up to the last phrase of the last
sentence…

… which only take a spinlock for legacy systems which did not have the
interlock instructions. No modern chip lacks them, and this is all lock
free.

I certainly understand what you mean (it can’t TRULY be “lock free” or it
wouldn’t work), but lest we mislead some poor unfortunate, it needs to be
pointed out that interlocked instructions on IA32 processors lock the memory
bus for the duration of the instruction. This is a very costly operation,
and what’s worse, it gets MORE impactful the more processors that there are
on the system.

Now, having said that, everything Daniel said is still true. And,
obviously, acquiring a spin lock on an MP system also requires an
interlocked instruction.

I’m going back to sleep now,

Peter
OSR


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

True enough. There is no free synchronization short of truly designing
it out of your system.

-----Original Message-----
From: Peter Viscarola [mailto:xxxxx@osr.com]
Sent: Wednesday, March 07, 2001 3:06 PM
To: File Systems Developers
Subject: [ntfsd] Re: efficiency of spin locks vs. eresource

I agree with everything danlo said, right up to the last phrase of the
last
sentence…

… which only take a spinlock for legacy systems which did not have
the
interlock instructions. No modern chip lacks them, and this is all
lock
free.

I certainly understand what you mean (it can’t TRULY be “lock free” or
it
wouldn’t work), but lest we mislead some poor unfortunate, it needs to
be
pointed out that interlocked instructions on IA32 processors lock the
memory
bus for the duration of the instruction. This is a very costly
operation,
and what’s worse, it gets MORE impactful the more processors that there
are
on the system.

Now, having said that, everything Daniel said is still true. And,
obviously, acquiring a spin lock on an MP system also requires an
interlocked instruction.

I’m going back to sleep now,

Peter
OSR


You are currently subscribed to ntfsd as: xxxxx@exchange.microsoft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OK Peter, it’s my turn to wake up.

The fun part of sharing memory on multi-processor systems is keeping the caches in step. There are various ways of doing this, but with a PII/PIII the writeback caches talk to each other, and when one CPU requires a cache line which is in another cache, and modified, the first CPU stops while the 2nd CPU’s cache updates main memory. It is possible to have systems where the caches are not automatically kept in step (eg: ICL 2900 mainframes) but they are unusual.

LOCK (the prefix which is used on semaphores) isn’t a particularily expensive operation. If it was we’d have major problems:

"LOCK - Assert LOCK# signal Prefix



“The XCHG Instruction always asserts LOCK# regardless of the presence or absence of the LOCK prefix”

You’ll find that WaitForSingleObject() uses a LOCK INC instruction, and takes no time flat - provided the object is available. You can get times for it by using the QueryPerformanceCounter/QueryPerformanceFrequency interfaces accurate to 1 CPU clock on a multi-processor system (ISTR to 1 bus clock on a single CPU system).

Oh, BTW: Modern CPUs? Even the 8086 has (had?) a LOCK instruction…

Andy

-----Original Message-----
From: Peter Viscarola [mailto:xxxxx@osr.com]
Sent: 07 March 2001 23:06
To: File Systems Developers
Subject: [ntfsd] Re: efficiency of spin locks vs. eresource

I agree with everything danlo said, right up to the last phrase of the last
sentence…

… which only take a spinlock for legacy systems which did not have the
interlock instructions. No modern chip lacks them, and this is all lock
free.

I certainly understand what you mean (it can’t TRULY be “lock free” or it
wouldn’t work), but lest we mislead some poor unfortunate, it needs to be
pointed out that interlocked instructions on IA32 processors lock the memory
bus for the duration of the instruction. This is a very costly operation,
and what’s worse, it gets MORE impactful the more processors that there are
on the system.

Now, having said that, everything Daniel said is still true. And,
obviously, acquiring a spin lock on an MP system also requires an
interlocked instruction.

I’m going back to sleep now,

Peter
OSR


Get your free email from AltaVista at http://altavista.iname.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

If Data structure is using only 1 Driver then better to use ERESOURCE.
If Data structure is accessing from Different Drivers u must use Spin lock.

Is above things are wrong ?

Regards,
Satish K.S

----- Original Message -----
From: “Daniel Lovinger”
To: “File Systems Developers”
Sent: Wednesday, March 07, 2001 2:10 AM
Subject: [ntfsd] Re: efficiency of spin locks vs. eresource

This is incorrect. The only way I can read out what you are saying is
that you believe that raising to DPC provides automatic inter-driver
synchronization. If this is the case, get thee a multi-processor machine
as quickly as possible. DPC is per-processor. Two threads can hold two
different spinlocks simultaneously.

So, you have to share a way of naming the same synchronization object.

So, you can use either.

ERESOURCES’s along with most every executive synchronization object
involve acquiring the dispatcher spinlock on each acquire/release. Your
decision is related more to how long you plan to be within the lock and
whether you actually can use the shared acquire mode of an ERESOURCE. If
you won’t, don’t even think about using them - just use a
mutex/spinlock.

If this is a simple push/pop list of workitems, consider using SLISTs.

ExInitializeSListHead
ExInterlockedPopEntrySList
ExInterlockedPushEntrySList

… which only take a spinlock for legacy systems which did not have the
interlock instructions. No modern chip lacks them, and this is all lock
free.

-----Original Message-----
From: Satish [mailto:xxxxx@aalayance.com]
Sent: Monday, March 05, 2001 9:07 PM
To: File Systems Developers
Subject: [ntfsd] Re: efficiency of spin locks vs. eresource

If Data structure is using only 1 Driver then better to use ERESOURCE.
If
Data structure is accessing from Different Drivers u must use Spin lock.

Regards,
Satish K.S

> This question might sound a bit off… but I am just wondering…
>
> Consider that I have a simple linked list which is being accessed by
alot
of
> threads. I need to synchronize this list between threads and I am
wondering
> if it would be better to use a spin lock to lock the list when
accessing
it
> in general or use ERESOURCE to lock it exclusively when items are
> added/removed and lock it shared when doing ptr = ptr->next_ptr.
>
> I guess I am just wondering if in this context it is expensive (or
makes
> sence) to use ERESOURCE… I am aware that spin locks operate by
raising
> IRQL which basically makes them extermely efficient in general… On
the
> other hand having shared access to the data would allow multiple
threads
> traverse the data in parallel.
>
> I’d appreciate to hear what you think.
>
> Thanks,
>
> Anton S. Yemelyanov
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@aalayance.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@exchange.microsoft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@aalayance.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

I dont think so - why would you think this?

You need to acquire the SAME eresource/spinlock in both cases so if two
drivers are sharing the data, you need to pass the lock (or an API to
acquire/release it) between the two…

/simgr

-----Original Message-----
From: Satish [mailto:xxxxx@aalayance.com]
Sent: Thursday, March 08, 2001 4:48 AM
To: File Systems Developers
Subject: [ntfsd] Re: efficiency of spin locks vs. eresource

If Data structure is using only 1 Driver then better to use ERESOURCE.
If Data structure is accessing from Different Drivers u must use Spin lock.

Is above things are wrong ?

Regards,
Satish K.S

----- Original Message -----
From: “Daniel Lovinger”
To: “File Systems Developers”
Sent: Wednesday, March 07, 2001 2:10 AM
Subject: [ntfsd] Re: efficiency of spin locks vs. eresource

This is incorrect. The only way I can read out what you are saying is
that you believe that raising to DPC provides automatic inter-driver
synchronization. If this is the case, get thee a multi-processor machine
as quickly as possible. DPC is per-processor. Two threads can hold two
different spinlocks simultaneously.

So, you have to share a way of naming the same synchronization object.

So, you can use either.

ERESOURCES’s along with most every executive synchronization object
involve acquiring the dispatcher spinlock on each acquire/release. Your
decision is related more to how long you plan to be within the lock and
whether you actually can use the shared acquire mode of an ERESOURCE. If
you won’t, don’t even think about using them - just use a
mutex/spinlock.

If this is a simple push/pop list of workitems, consider using SLISTs.

ExInitializeSListHead
ExInterlockedPopEntrySList
ExInterlockedPushEntrySList

… which only take a spinlock for legacy systems which did not have the
interlock instructions. No modern chip lacks them, and this is all lock
free.

-----Original Message-----
From: Satish [mailto:xxxxx@aalayance.com]
Sent: Monday, March 05, 2001 9:07 PM
To: File Systems Developers
Subject: [ntfsd] Re: efficiency of spin locks vs. eresource

If Data structure is using only 1 Driver then better to use ERESOURCE.
If
Data structure is accessing from Different Drivers u must use Spin lock.

Regards,
Satish K.S

> This question might sound a bit off… but I am just wondering…
>
> Consider that I have a simple linked list which is being accessed by
alot
of
> threads. I need to synchronize this list between threads and I am
wondering
> if it would be better to use a spin lock to lock the list when
accessing
it
> in general or use ERESOURCE to lock it exclusively when items are
> added/removed and lock it shared when doing ptr = ptr->next_ptr.
>
> I guess I am just wondering if in this context it is expensive (or
makes
> sence) to use ERESOURCE… I am aware that spin locks operate by
raising
> IRQL which basically makes them extermely efficient in general… On
the
> other hand having shared access to the data would allow multiple
threads
> traverse the data in parallel.
>
> I’d appreciate to hear what you think.
>
> Thanks,
>
> Anton S. Yemelyanov
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@aalayance.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@exchange.microsoft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@aalayance.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@stratus.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Two driver mean here i considered 1 is my driver and another is different
Not my driver ).
This case We must use Spin lock right ? we cant use ERESOURCE right ?

----- Original Message -----
From: “Graham, Simon”
To: “File Systems Developers”
Sent: Thursday, March 08, 2001 6:46 PM
Subject: [ntfsd] Re: efficiency of spin locks vs. eresource

> I dont think so - why would you think this?
>
> You need to acquire the SAME eresource/spinlock in both cases so if two
> drivers are sharing the data, you need to pass the lock (or an API to
> acquire/release it) between the two…
>
> /simgr
>
>
> -----Original Message-----
> From: Satish [mailto:xxxxx@aalayance.com]
> Sent: Thursday, March 08, 2001 4:48 AM
> To: File Systems Developers
> Subject: [ntfsd] Re: efficiency of spin locks vs. eresource
>
>
> If Data structure is using only 1 Driver then better to use ERESOURCE.
> If Data structure is accessing from Different Drivers u must use Spin
lock.
>
> Is above things are wrong ?
>
> Regards,
> Satish K.S
>
> ----- Original Message -----
> From: “Daniel Lovinger”
> To: “File Systems Developers”
> Sent: Wednesday, March 07, 2001 2:10 AM
> Subject: [ntfsd] Re: efficiency of spin locks vs. eresource
>
>
> This is incorrect. The only way I can read out what you are saying is
> that you believe that raising to DPC provides automatic inter-driver
> synchronization. If this is the case, get thee a multi-processor machine
> as quickly as possible. DPC is per-processor. Two threads can hold two
> different spinlocks simultaneously.
>
> So, you have to share a way of naming the same synchronization object.
>
> So, you can use either.
>
> ERESOURCES’s along with most every executive synchronization object
> involve acquiring the dispatcher spinlock on each acquire/release. Your
> decision is related more to how long you plan to be within the lock and
> whether you actually can use the shared acquire mode of an ERESOURCE. If
> you won’t, don’t even think about using them - just use a
> mutex/spinlock.
>
> If this is a simple push/pop list of workitems, consider using SLISTs.
>
> ExInitializeSListHead
> ExInterlockedPopEntrySList
> ExInterlockedPushEntrySList
>
> … which only take a spinlock for legacy systems which did not have the
> interlock instructions. No modern chip lacks them, and this is all lock
> free.
>
> -----Original Message-----
> From: Satish [mailto:xxxxx@aalayance.com]
> Sent: Monday, March 05, 2001 9:07 PM
> To: File Systems Developers
> Subject: [ntfsd] Re: efficiency of spin locks vs. eresource
>
> If Data structure is using only 1 Driver then better to use ERESOURCE.
> If
> Data structure is accessing from Different Drivers u must use Spin lock.
>
> Regards,
> Satish K.S
>
> > This question might sound a bit off… but I am just wondering…
> >
> > Consider that I have a simple linked list which is being accessed by
> alot
> of
> > threads. I need to synchronize this list between threads and I am
> wondering
> > if it would be better to use a spin lock to lock the list when
> accessing
> it
> > in general or use ERESOURCE to lock it exclusively when items are
> > added/removed and lock it shared when doing ptr = ptr->next_ptr.
> >
> > I guess I am just wondering if in this context it is expensive (or
> makes
> > sence) to use ERESOURCE… I am aware that spin locks operate by
> raising
> > IRQL which basically makes them extermely efficient in general… On
> the
> > other hand having shared access to the data would allow multiple
> threads
> > traverse the data in parallel.
> >
> > I’d appreciate to hear what you think.
> >
> > Thanks,
> >
> > Anton S. Yemelyanov
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@aalayance.com
> > To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@exchange.microsoft.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntfsd as: xxxxx@aalayance.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@stratus.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntfsd as: xxxxx@aalayance.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Satish, you are very badly confused about kernel synchronization
objects. Could you please explain why you think this is the case so we
can help you? If it is just inter vs. intra driver, trust me, this is
completely irrelevant.

-----Original Message-----
From: Satish [mailto:xxxxx@aalayance.com]
Sent: Thursday, March 08, 2001 5:28 AM
To: File Systems Developers
Subject: [ntfsd] Re: efficiency of spin locks vs. eresource

Two driver mean here i considered 1 is my driver and another is
different
Not my driver ).
This case We must use Spin lock right ? we cant use ERESOURCE right ?

----- Original Message -----
From: “Graham, Simon”
To: “File Systems Developers”
Sent: Thursday, March 08, 2001 6:46 PM
Subject: [ntfsd] Re: efficiency of spin locks vs. eresource

> I dont think so - why would you think this?
>
> You need to acquire the SAME eresource/spinlock in both cases so if
two
> drivers are sharing the data, you need to pass the lock (or an API to
> acquire/release it) between the two…
>
> /simgr
>
>
> -----Original Message-----
> From: Satish [mailto:xxxxx@aalayance.com]
> Sent: Thursday, March 08, 2001 4:48 AM
> To: File Systems Developers
> Subject: [ntfsd] Re: efficiency of spin locks vs. eresource
>
>
> If Data structure is using only 1 Driver then better to use ERESOURCE.
> If Data structure is accessing from Different Drivers u must use Spin
lock.
>
> Is above things are wrong ?
>
> Regards,
> Satish K.S
>
> ----- Original Message -----
> From: “Daniel Lovinger”
> To: “File Systems Developers”
> Sent: Wednesday, March 07, 2001 2:10 AM
> Subject: [ntfsd] Re: efficiency of spin locks vs. eresource
>
>
> This is incorrect. The only way I can read out what you are saying is
> that you believe that raising to DPC provides automatic inter-driver
> synchronization. If this is the case, get thee a multi-processor
machine
> as quickly as possible. DPC is per-processor. Two threads can hold
two
> different spinlocks simultaneously.
>
> So, you have to share a way of naming the same synchronization object.
>
> So, you can use either.
>
> ERESOURCES’s along with most every executive synchronization object
> involve acquiring the dispatcher spinlock on each acquire/release.
Your
> decision is related more to how long you plan to be within the lock
and
> whether you actually can use the shared acquire mode of an ERESOURCE.
If
> you won’t, don’t even think about using them - just use a
> mutex/spinlock.
>
> If this is a simple push/pop list of workitems, consider using SLISTs.
>
> ExInitializeSListHead
> ExInterlockedPopEntrySList
> ExInterlockedPushEntrySList
>
> … which only take a spinlock for legacy systems which did not have
the
> interlock instructions. No modern chip lacks them, and this is all
lock
> free.
>
> -----Original Message-----
> From: Satish [mailto:xxxxx@aalayance.com]
> Sent: Monday, March 05, 2001 9:07 PM
> To: File Systems Developers
> Subject: [ntfsd] Re: efficiency of spin locks vs. eresource
>
> If Data structure is using only 1 Driver then better to use ERESOURCE.
> If
> Data structure is accessing from Different Drivers u must use Spin
lock.
>
> Regards,
> Satish K.S
>
> > This question might sound a bit off… but I am just wondering…
> >
> > Consider that I have a simple linked list which is being accessed by
> alot
> of
> > threads. I need to synchronize this list between threads and I am
> wondering
> > if it would be better to use a spin lock to lock the list when
> accessing
> it
> > in general or use ERESOURCE to lock it exclusively when items are
> > added/removed and lock it shared when doing ptr = ptr->next_ptr.
> >
> > I guess I am just wondering if in this context it is expensive (or
> makes
> > sence) to use ERESOURCE… I am aware that spin locks operate by
> raising
> > IRQL which basically makes them extermely efficient in general… On
> the
> > other hand having shared access to the data would allow multiple
> threads
> > traverse the data in parallel.
> >
> > I’d appreciate to hear what you think.
> >
> > Thanks,
> >
> > Anton S. Yemelyanov
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@aalayance.com
> > To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@exchange.microsoft.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntfsd as: xxxxx@aalayance.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@stratus.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntfsd as: xxxxx@aalayance.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@exchange.microsoft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Just wanted to thank everyone for feedback to my question.

I would have to agree with Vladimir who said that probably the best thing to
do is to implement, test both methods and see which one is faster.

ASY


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Yea Same thing i will agree. Testing both things and deciding which serves
ur needs is best.

Regards,
Satish K.S

----- Original Message -----
From: “Anton S. Yemelyanov”
To: “File Systems Developers”
Sent: Monday, March 12, 2001 11:27 PM
Subject: [ntfsd] Re: efficiency of spin locks vs. eresource

> Just wanted to thank everyone for feedback to my question.
>
> I would have to agree with Vladimir who said that probably the best thing
to
> do is to implement, test both methods and see which one is faster.
>
> ASY
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@aalayance.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

>CPU’s cache updates main memory. It is possible to have systems where the

caches are not automatically kept in step (eg: ICL 2900 mainframes) but
they
are unusual.

PowerPC AIX machines seem to be such too.

I know one guy who has an AIX kmode experience. He asked me once on “what
instructions must be executed on x86 to maintain the cache coherency?”. He
was very much surprised with my answer of “no instructions, hardware does it
without any software aid”.

Max


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com