http://groups.google.com/group/comp.programming.threads?hl=en
comp.programming.threads@googlegroups.com
Today's topics:
* Maximum Threads supported on Windows server 2003 - 1 messages, 1 author
http://groups.google.com/group/comp.programming.threads/t/2d900ff3e045fe10?hl=en
* strong atomic reference counting... - 1 messages, 1 author
http://groups.google.com/group/comp.programming.threads/t/1b35d9cff58efb83?hl=en
* amortizing read-access in read/write mutex... - 1 messages, 1 author
http://groups.google.com/group/comp.programming.threads/t/7b92af0a72a360ba?hl=en
==============================================================================
TOPIC: Maximum Threads supported on Windows server 2003
http://groups.google.com/group/comp.programming.threads/t/2d900ff3e045fe10?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Feb 3 2010 8:08 pm
From: Jonathan de Boyne Pollard
>
>
> We are developing a server application ,we have decided to adopt
> windows 2003/2008 server. We want to know the theoritical analysis as
> for as number of threads and process these server can support
> considering following paramerts
> 1. RAM
> 2. No of CPU
> 3. 32/64 bit processor
>
> Q1 What will be the maximum limit for threads (in the same process)
> considering above parameter ?
> Q2 What will be the maximum limit for total application at a time can
> run,considering above parameter ?
>
Q: How many copies of Manish can fit into this room?
R: How big is Manish? How big is the room? Will xe be standing stock
still or jigging around like a madman?
==============================================================================
TOPIC: strong atomic reference counting...
http://groups.google.com/group/comp.programming.threads/t/1b35d9cff58efb83?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Feb 4 2010 3:04 pm
From: Marcel Müller
Chris M. Thomasson wrote:
> "Marcel M�ller" <news.5.maazl@spamgourmet.com> wrote in message
> news:4b69ad47$0$7626$9b4e6d93@newsspool1.arcor-online.net...
>> Chris M. Thomasson wrote:
>>> IMVHO, it's nice to be able to remove the CAS-loop from in the
>>> function that acquires strong references. Anyway, what do you think
>>> of the technique?
>>
>> Once I completed to move my home I will have a look at this.
>>
>> But I currently already have an implementation without a CAS loop and
>> with only one machine size word memory footprint. (The stolen bits
>> trick, but without the restriction in the number of active
>> references.) Unfortunately not very well tested so far.
>
> Now that's pretty interesting because the "stolen bits" are typically
> used to actually represent the reference count itself. Therefore, I
> would very much like to examine your algorithm Marcel.
The primary reference counter is intrusive in my case. (Implemented by
deriving from a base class.) However, that does not make any difference.
But the additional counter for strong thread safety works with stolen
bits. The basic idea is that this counter value is moved to the primary
reference counter immediately after the local reference is acquired from
the shared pointer. This creates a frequency distribution of values that
drops exponentially with increasing value. In fact I never was able to
increment the counter with the stolen bits above 2 in test applications
with some dozen threads. Even this is non-trivial. Since most platforms
provide at least 32 bit alignment, the two superfluous bits are usually
sufficient and no special allocator is required.
> BTW, have you ever played around with Dmitriy Vyukov's Relacy Race
> Detector?
I had a look at it when I developed the above algo. But I stopped at the
point when I realized that porting to my platform is required. On
eComStation I am restricted to gcc 3.3 (no std::atomic) and have no
posix compatibility.
Marcel
==============================================================================
TOPIC: amortizing read-access in read/write mutex...
http://groups.google.com/group/comp.programming.threads/t/7b92af0a72a360ba?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Feb 4 2010 9:14 pm
From: David Schwartz
I added an implementation to my Linux-specific futex-based reader/
writer lock. Fast paths are fully optimized. Any reports of problems
noted would be helpful.
Here's the implementation. We use a few non-standard primitives:
InterlockedGet(&x) is kind of like *(volatile int *)x
InterlockedInc and InterlockedDec are atomic increments and decrements
that don't return anything.
InterlockedIncrement and InterlockedDecrement are atomic increments
and decrements that return zero if and only if the resulting value is
zero.
InterlockedExchange(&x, y) is an atomic *x=y that returns the original
value of *x
Also, if you're not familiar with the futex operations, we use only
two. FUTEX_WAIT and FUTEX_WAKE. For example:
sys_futex(&writers, FUTEX_WAIT, j, NULL);
This says to atomically check if writers==j, and if not, to block on
the writers futex.
sys_futex(&areaders, FUTEX_WAKE, 1, NULL);
This says to wake 1 thread that is blocked on the areaders futex.
Any integer can become a futex simply by a thread blocking on it.
Here it is:
// Copyright David J. Schwartz <davids@webmaster.com>, 2006-2010
// All rights reserved
// Offered without any warranty or claim of fitness for any purpose
class RWFutex
{
protected:
int areaders; // number of active readers (active writer blocks for
zero)
int pad1; // pads give each hot variable its own cache line
int wreaders; // number of waiting readers
int pad2;
int writers; // count of active/waiting writers (readers block for
zero)
int pad3;
int writer; // lock the active writer holds (other writers block
for zero)
int pad4;
private:
RWFutex(const RWFutex &); // no implementation
RWFutex &operator=(const RWFutex &); // no implementation
public:
RWFutex(void) : areaders(0), wreaders(0), writers(0), writer(0) { ; }
void ReadLock(void)
{
int j;
while(1)
{
if(InterlockedGet(&writers)!=0)
{ // wait for no writers
InterlockedInc(&wreaders);
while((j=InterlockedGet(&writers))!=0)
sys_futex(&writers, FUTEX_WAIT, j, NULL);
InterlockedDec(&wreaders);
}
InterlockedInc(&areaders); // add us as a reader
if(InterlockedGet(&writer)==0) // did we race with a writer?
return; // no
if(InterlockedDecrement(&areaders)==0) // we were only attempting
reader
if(InterlockedGet(&writers)!=0) // there is at least one waiting
writer
sys_futex(&areaders, FUTEX_WAKE, 1, NULL);
}
}
bool TryReadLock(void)
{
if(InterlockedGet(&writers)!=0) return false; // active/waiting
writers
InterlockedInc(&areaders);
if(InterlockedGet(&writer)==0) // did we race?
return true;
if(InterlockedDecrement(&areaders)==0) // we are only attempting
reader
sys_futex(&areaders, FUTEX_WAKE, 1, NULL);
return false;
}
void ReadUnlock(void)
{
if(InterlockedDecrement(&areaders)!=0) // one less reader
return; // still other readers
if(InterlockedGet(&writers)!=0) // a writer awaits
sys_futex(&areaders, FUTEX_WAKE, 1, NULL); // no readers now
}
bool CondReadUnlock(void)
{ // unlock read if there's a waiting writer and return when writer
is done
if(InterlockedGet(&writers)==0) return false;
ReadUnlock();
ReadLock();
return true;
}
void WriteLock(void)
{
int j;
InterlockedInc(&writers);
while(fInterlockedExchange(&writer, 1)!=0) // wait out other writers
sys_futex(&writer, FUTEX_WAIT, 1, NULL); // optimizable slow path
// we are the only writer
while((j=InterlockedGet(&areaders))!=0) // wait for no readers
sys_futex(&areaders, FUTEX_WAIT, j, NULL);
}
bool TryWriteLock(void)
{
if( (InterlockedGet(&writers)!=0) || (InterlockedGet(&areaders)!
=0) )
return false;
InterlockedInc(&writers); // add us as a writer
if(InterlockedExchange(&writer, 1)!=0) // can we grab the lock
{ // no, did we block anyone?
if(InterlockedDecrement(&writers)!=0) // waiting writer
sys_futex(&writer, FUTEX_WAKE, 1, NULL); // wake him
else if(InterlockedGet(&wreaders)!=0) // waiting reader(s)
sys_futex(&writers, FUTEX_WAKE, INT_MAX, NULL); // wake them
return false;
}
if(InterlockedGet(&areaders)==0) // if no readers, we're done
return true;
InterlockedSet(&writer, 0); // we raced with a reader, release write
lock
if(InterlockedDecrement(&writers)!=0) // waiting writer
sys_futex(&writer, FUTEX_WAKE, 1, NULL); // wake him
else if(InterlockedGet(&wreaders)!=0) // waiting reader(s)
sys_futex(&writers, FUTEX_WAKE, INT_MAX, NULL); // wake them
return false;
}
void WriteUnlock(void)
{
__asm__ __volatile__("" : : : "memory");
InterlockedSet(&writer, 0); // no active writer, no active readers
if(InterlockedDecrement(&writers)!=0) // waiting writer
sys_futex(&writer, FUTEX_WAKE, 1, NULL); // wake writer
else if(InterlockedGet(&wreaders)!=0) // waiting reader(s)
sys_futex(&writers, FUTEX_WAKE, INT_MAX, NULL); // wake readers
}
};
Comments appreciated. I've had this code percolating for many years
but never actually used it in anything deployed.
DS
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.programming.threads"
group.
To post to this group, visit http://groups.google.com/group/comp.programming.threads?hl=en
To unsubscribe from this group, send email to comp.programming.threads+unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.programming.threads/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
No comments:
Post a Comment