Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Clarification on the applicability of compile-time optimization to astruct variable which encompasses a mixture of fields declared as volatileand non-volatile individually

Reply
Thread Tools

Clarification on the applicability of compile-time optimization to astruct variable which encompasses a mixture of fields declared as volatileand non-volatile individually

 
 
Joshua Maurice
Guest
Posts: n/a
 
      07-07-2012
On Jul 6, 3:54*pm, Uncle Steve <(E-Mail Removed)> wrote:
> On Fri, Jul 06, 2012 at 07:39:56PM -0700, Joshua Maurice wrote:
> > I will say it again: the C89 and C99 standards do not mean what you
> > think. What the compiler writers and thread library writers understand
> > volatile to mean is not what you understand volatile to mean, and at
> > the end of the day what the compiler writers and thread library
> > writers think is paramount. You may be able to get this to work for
> > specific platforms with specific compilers. I suggest you ask in a
> > location specific to such implementations for such platform specific
> > hackery. However, do not look at the C standard for guidance on this.

>
> Um, what is it that compiler writers and thread library writers
> understand volatile to mean?


http://www.open-std.org/jtc1/sc22/wg...006/n2016.html

> > In the C11 parlance, what you're trying to write requires the "weak"
> > atomics, such as relaxed, acquire, release, and consume memory
> > operations. Attempting to write stuff like this without C11 support
> > with the C11 primitives is a wholly platform specific affair, and
> > neither C89 nor C90 can help you there. volatile specifically cannot
> > help you (barring platform specific documentation to the contrary).

>
> You seem to be making too many assumptions about my code.


I think it's pretty clear from what you've written else-thread.

> > From else-thread:
> > On Jul 6, 2:29 pm, Uncle Steve <(E-Mail Removed)> wrote:
> > > On Sat, Jul 07, 2012 at 12:37:59PM +1200, Ian Collins wrote:
> > > > Then use your platform's native threading primitives.

>
> > > Doing so would incur a performance penalty in comparison to my
> > > synchronization primitives in some circumstances.

>
> > That's your problem. You have broken code. Your options are:
> > 1- broken code (e.g. using volatile and asm memory barriers absent
> > platform specific guarantees)
> > 2- code that relies on platform specific guarantees (e.g. with using
> > volatile and asm memory barriers)
> > 3- "slow" code (e.g. with posix mutexes)
> > 4- C11 code

>
> How do you know, a priori, that my code is broken? *Do I have to
> change my passwords again?


How do I know it's broken? By your own admission, you're using
volatile to try and affect inter-thread visibility (absent constructs
that actually give inter-thread visibility). By your previous
statements about using the C standard to derive useful threading
semantics for volatile, I doubt you've looked at the compiler
documentation and hardware documentation for your implementation. Thus
you have broken code. (I don't think you are trying to nit on "it
could be right by coincidence".)
 
Reply With Quote
 
 
 
 
Joshua Maurice
Guest
Posts: n/a
 
      07-07-2012
On Jul 6, 4:25*pm, Uncle Steve <(E-Mail Removed)> wrote:
> On Fri, Jul 06, 2012 at 08:12:57PM -0700, Joshua Maurice wrote:
> > On Jul 6, 3:54*pm, Uncle Steve <(E-Mail Removed)> wrote:
> > > On Fri, Jul 06, 2012 at 07:39:56PM -0700, Joshua Maurice wrote:
> > > > I will say it again: the C89 and C99 standards do not mean what you
> > > > think. What the compiler writers and thread library writers understand
> > > > volatile to mean is not what you understand volatile to mean, and at
> > > > the end of the day what the compiler writers and thread library
> > > > writers think is paramount. You may be able to get this to work for
> > > > specific platforms with specific compilers. I suggest you ask in a
> > > > location specific to such implementations for such platform specific
> > > > hackery. However, do not look at the C standard for guidance on this.

>
> > > Um, what is it that compiler writers and thread library writers
> > > understand volatile to mean?

>
> >http://www.open-std.org/jtc1/sc22/wg...006/n2016.html

>
> > > > In the C11 parlance, what you're trying to write requires the "weak"
> > > > atomics, such as relaxed, acquire, release, and consume memory
> > > > operations. Attempting to write stuff like this without C11 support
> > > > with the C11 primitives is a wholly platform specific affair, and
> > > > neither C89 nor C90 can help you there. volatile specifically cannot
> > > > help you (barring platform specific documentation to the contrary).

>
> > > You seem to be making too many assumptions about my code.

>
> > I think it's pretty clear from what you've written else-thread.

>
> > > > From else-thread:
> > > > On Jul 6, 2:29 pm, Uncle Steve <(E-Mail Removed)> wrote:
> > > > > On Sat, Jul 07, 2012 at 12:37:59PM +1200, Ian Collins wrote:
> > > > > > Then use your platform's native threading primitives.

>
> > > > > Doing so would incur a performance penalty in comparison to my
> > > > > synchronization primitives in some circumstances.

>
> > > > That's your problem. You have broken code. Your options are:
> > > > 1- broken code (e.g. using volatile and asm memory barriers absent
> > > > platform specific guarantees)
> > > > 2- code that relies on platform specific guarantees (e.g. with using
> > > > volatile and asm memory barriers)
> > > > 3- "slow" code (e.g. with posix mutexes)
> > > > 4- C11 code

>
> > > How do you know, a priori, that my code is broken? *Do I have to
> > > change my passwords again?

>
> > How do I know it's broken? By your own admission, you're using
> > volatile to try and affect inter-thread visibility (absent constructs
> > that actually give inter-thread visibility). By your previous
> > statements about using the C standard to derive useful threading
> > semantics for volatile, I doubt you've looked at the compiler
> > documentation and hardware documentation for your implementation. Thus
> > you have broken code. (I don't think you are trying to nit on "it
> > could be right by coincidence".)

>
> Well you know what? *You're going to have to wait until version 1.0
> before you get to decide how wrong it is.


Let me share with you a story. I currently work for a company selling
Enterprise software. The software is heavily intertwined with
databases. We have a license for a large piece of code that does heavy
duty sorting. We have a contract with the guys who wrote this sorting
library for support and maintenance. One of our customers upgraded
some of their hardware, ran some tests - or possibly worse ran actual
usage - and noticed that one row out of a few billion was "missing".
Our engine dropped it, somewhere. It should be in the output, but it
wasn't. Of course, this is very bad for our company. This could cost
millions of dollars in sales. So, we get the guys who wrote the
sorting library, and immediately fly them out to us. We get them to
work on the code. I was only tangentially related to this process. It
took a week or so of work to find and fix the issue. What was the
problem? The guys who wrote the sorting library used "volatile", and
the customer just upgraded to some itanium processor or something. A
quick fix/hack later, and our customer was back in business, our
millions of dollars was secure, as was our company image and
reputation.

Use volatile at your own risk. I don't plan on using your software if
I can help it.
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      07-07-2012
On 07/ 7/12 09:29 AM, Uncle Steve wrote:
> On Sat, Jul 07, 2012 at 12:37:59PM +1200, Ian Collins wrote:
>> On 07/ 7/12 08:27 AM, Uncle Steve wrote:
>>> On Sat, Jul 07, 2012 at 11:29:02AM +1200, Ian Collins wrote:
>>>> On 07/ 7/12 06:33 AM, Uncle Steve wrote:
>>>>>
>>>>> Is there are C standard threading framework?
>>>>
>>>> Yes, read C11. If you are familiar with pthreads, you'll see where most
>>>> of the new primitives originate.
>>>
>>> Well, I don't follow gcc development, so I don't know when those
>>> features will be available on my system.

>>
>> Then use your platform's native threading primitives.

>
> Doing so would incur a performance penalty in comparison to my
> synchronization primitives in some circumstances.


In other words, correctness would incur a performance penalty in
comparison to your synchronization primitives in some circumstances.

>>> O.K., so do nested structure elements inherit the parent structure's
>>> volatile attribute?

>>
>> A volatile T is a volatile T no matter what it contains.

>
> Look. In threaded applications, the truth associated with the value
> associated with certain variables can be somewhat indeterminate. If
> that's true in your code, you might want to be aware of it.


If I could parse that, I'd respond to it.

>>>>> While the specifics of an implementation within a given operating
>>>>> system are not C issues, certain common optimizations can be a problem
>>>>> with certain algorithms, and so there ought to be a C solution to the
>>>>> problem. What is it about the volatile attribute that makes it
>>>>> insufficient in your mind to the problem presented by threaded code?
>>>>
>>>> Given you are the one going against conventional wisdom, what in your
>>>> mind makes volatile a solution to the problem presented by threaded code?
>>>>
>>>> In addition, what is "the problem presented by threaded code"?
>>>
>>> Well, code optimization from global CSE might eliminate memory
>>> accesses to variable that could be modified by other threads in ways
>>> that affect the algorithm. Depends of the code.

>>
>> If the code depends on volatile, it is broken. Use the atomics or
>> synchronisation primitives provided by the language or platform. They
>> exist for a reason.

>
> You aren't listening to me.


You aren't making much sense.

An example of you your synchronization primitives would clear things up.

--
Ian Collins
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      07-07-2012
Uncle Steve <(E-Mail Removed)> writes:

> What is it about the volatile attribute that makes it
> insufficient in your mind to the problem presented by
> threaded code?


Let's take a specific example:

volatile int a = 1, b = 2;

... start up threads X and Y ...

... in parallel ... {

... in thread X ... {
a = 3;
b = 4;
}

... in thread Y ... {
printf( "a = %d\n", a );
printf( "b = %d\n", b );
}

}

Question: what values for a and b might thread Y print?

Answer: Besides the obvious possibilities of {1,2}, {3,2},
and {3,4}, the Standard allows a conforming implementation
to define volatile access in such a way that thread Y might
print 1 for a but 4 for b. In other words, using volatile
is not enough to guarantee write ordering. Moreover that
lack of guarantee holds true even if write-barrier opcodes
are used before and after each volatile-qualified access.

So it's kind of unfortunate but true - the meaning of volatile
is inherently non-portable. You may be able to write code
using volatile to do inter-thread communication that works
reliably on a number of implementations, but that depends
on decisions made by those implementations, and not just on
the Standard.


> I don't have a copy of the standard, [...]


Easily solved. For C99:

http://www.open-std.org/jtc1/sc22/wg...docs/n1256.pdf

For C11:

http://www.open-std.org/jtc1/sc22/wg...docs/n1570.pdf
 
Reply With Quote
 
Uncle Steve
Guest
Posts: n/a
 
      07-07-2012
On Sat, Jul 07, 2012 at 12:10:02AM -0700, Tim Rentsch wrote:
> Uncle Steve <(E-Mail Removed)> writes:
>
> > What is it about the volatile attribute that makes it
> > insufficient in your mind to the problem presented by
> > threaded code?

>
> Let's take a specific example:
>
> volatile int a = 1, b = 2;
>
> ... start up threads X and Y ...
>
> ... in parallel ... {
>
> ... in thread X ... {
> a = 3;
> b = 4;
> }
>
> ... in thread Y ... {
> printf( "a = %d\n", a );
> printf( "b = %d\n", b );
> }
>
> }
>
> Question: what values for a and b might thread Y print?
>
> Answer: Besides the obvious possibilities of {1,2}, {3,2},
> and {3,4}, the Standard allows a conforming implementation
> to define volatile access in such a way that thread Y might
> print 1 for a but 4 for b. In other words, using volatile
> is not enough to guarantee write ordering. Moreover that
> lack of guarantee holds true even if write-barrier opcodes
> are used before and after each volatile-qualified access.
>
> So it's kind of unfortunate but true - the meaning of volatile
> is inherently non-portable. You may be able to write code
> using volatile to do inter-thread communication that works
> reliably on a number of implementations, but that depends
> on decisions made by those implementations, and not just on
> the Standard.


I never said I was relying on the volatile attribute exclusively to
provide coherence between threads. The bug up my butt concerning the
volatile keyword is more related to presenting consistent results in
d ata structures that might transition several states quickly, and I
don't want the presentation of those states to be optimized out
simply because the compiler decides it can.

I showed the potential for this in the simple timing code I posted
earlier. Note that removing the volatile qualifier from variables
that have them changes the output. So, my interest in the volatile
attribute is not related to thread synchronization so much as it is in
general data coherence in a complex threaded application.

Note that I have not yet found out whether structure attributes
propogate to substructures that are structure elements.

> > I don't have a copy of the standard, [...]

>
> Easily solved. For C99:
>
> http://www.open-std.org/jtc1/sc22/wg...docs/n1256.pdf
>
> For C11:
>
> http://www.open-std.org/jtc1/sc22/wg...docs/n1570.pdf


Thanks, I'll have a look.

I've been reviewing the code I posted previously, and I can no longer
make it malfunction the way it was breaking. I forget what I changed,
so I'm going to have to check into it before I can better illustrate
the phenomenon.



Regards,

Uncle Steve

--
The moon has never been closer.

 
Reply With Quote
 
Uncle Steve
Guest
Posts: n/a
 
      07-07-2012
On Sat, Jul 07, 2012 at 08:16:53AM -0400, Eric Sosman wrote:
> On 7/6/2012 2:33 PM, Uncle Steve wrote:
> >On Fri, Jul 06, 2012 at 06:11:28PM -0400, Eric Sosman wrote:
> >>[...]
> >> Although the latest "C11" Standard adds some multi-threading
> >>support, [...]
> >>
> >> [...]I suggest you visit comp.programming.threads,
> >>a newsgroup devoted to multi-threading issues. There you will learn
> >>that `volatile' is neither necessary *nor* sufficient in connection
> >>with variables shared between threads. [...]

> >
> >Is there are C standard threading framework?

>
> See above.
>
> >Threaded code is a de-facto reality in today's multi-core environment.
> >Save for the embedded sector, most systems will run threads in
> >parallel, and that is that. C has to recognize this watershed moment
> >in the refinement of the language.

>
> See above.
>
> >What is it about the volatile attribute that makes it
> >insufficient in your mind to the problem presented by threaded code?

>
> "Then Kolokolo Bird said, with a mournful cry, 'Go to the banks of
> the great grey-green, greasy Limpopo River -- er, that is, the G,G-G,G
> comp.programming.threads newsgroup -- all set about with fever-trees,
> and find out.'"
>
> By "go," I mean "go away," as in "Don't continue this thread in
> comp.lang.c unless you specifically wish to discuss the threading
> features of C11." Follow-ups set.


Your message excells as an example of myopic religious orthodoxy. I'm
not actually suggesting that there should be changes to the standard,
so I don't quite understand why you seem so threatened.


Regards,

Uncle Steve

--
The moon has never been closer.

 
Reply With Quote
 
Uncle Steve
Guest
Posts: n/a
 
      07-07-2012
On Sat, Jul 07, 2012 at 09:24:25AM -0400, Eric Sosman wrote:
> On 7/7/2012 5:12 AM, Uncle Steve wrote:
> >On Sat, Jul 07, 2012 at 08:16:53AM -0400, Eric Sosman wrote:
> >>On 7/6/2012 2:33 PM, Uncle Steve wrote:
> >>>On Fri, Jul 06, 2012 at 06:11:28PM -0400, Eric Sosman wrote:
> >>>>[...]
> >>>> Although the latest "C11" Standard adds some multi-threading
> >>>>support, [...]
> >>>>
> >>>> [...]I suggest you visit comp.programming.threads,
> >>>>a newsgroup devoted to multi-threading issues. There you will learn
> >>>>that `volatile' is neither necessary *nor* sufficient in connection
> >>>>with variables shared between threads. [...]
> >>>
> >>>Is there are C standard threading framework?
> >>
> >> See above.
> >>
> >>>Threaded code is a de-facto reality in today's multi-core environment.
> >>>Save for the embedded sector, most systems will run threads in
> >>>parallel, and that is that. C has to recognize this watershed moment
> >>>in the refinement of the language.
> >>
> >> See above.
> >>
> >>>What is it about the volatile attribute that makes it
> >>>insufficient in your mind to the problem presented by threaded code?
> >>
> >> "Then Kolokolo Bird said, with a mournful cry, 'Go to the banks of
> >>the great grey-green, greasy Limpopo River -- er, that is, the G,G-G,G
> >>comp.programming.threads newsgroup -- all set about with fever-trees,
> >>and find out.'"
> >>
> >> By "go," I mean "go away," as in "Don't continue this thread in
> >>comp.lang.c unless you specifically wish to discuss the threading
> >>features of C11." Follow-ups set.

> >
> >Your message excells as an example of myopic religious orthodoxy. I'm
> >not actually suggesting that there should be changes to the standard,
> >so I don't quite understand why you seem so threatened.

>
> When you ask (somewhat incoherently) "Is there are C standard
> threading framework," which part of
>
> THE LATEST "C11" STANDARD ADDS SOME MULTI-THREADING SUPPORT
>
> are you having trouble understanding?
>
> C11's threading support is on-topic here in comp.lang.c -- but
> you've indicated that you're not interested in C11 threads and in fact
> are using Pthreads instead. Pthreads is off-topic here, so please help
> reduce the noise by removing the discussion to comp.programming.threads
> which "excells" [sic] on that topic.


It was previously mentioned that C11 threads were copied from
pthreads, although presumably there would be some difference in
semantics. Please don't cut off my hands if I inadvertently say
something against the standard, eh? I approve of standards, and I'm
not just saying that to get on your good side.


Regards,

Uncle Steve

--
The moon has never been closer.

 
Reply With Quote
 
Uncle Steve
Guest
Posts: n/a
 
      07-07-2012
On Sat, Jul 07, 2012 at 03:47:38PM +0200, Jens Gustedt wrote:
> Am 07.07.2012 01:58, schrieb Joshua Maurice:
>
> > To be topical, here's the answer for C11: volatile is useless as a
> > portable threading construct. Do not use it. It's (maybe) useful in a
> > portable way only for 3 obscure situations: MMIO, setjmp and longjmp
> > stuff, and signal handling.

>
> No, this is misleading. volatile alone is not sufficient to warrant data
> consistency between threads, but is necessary. volatile and _Atomic are
> complementary specifications that *both* are needed if you want to make
> sure that a thread always uses the latest stored value of a variable. If
> you have
>
> static int _Atomic a = ATOMIC_VAR_INIT(23);
> if (tester)
> for (; printf("current value is %d\n", a);
>
> The compiler is allowed to change the loop into something equivalent to
>
> {
> int tmp = a; // do an atomic_load operation here
> for (; printf("current value is %d\n", tmp);
> }
>
> and thus always print the same value.
>
> static int _Atomic volatile a = ATOMIC_VAR_INIT(23);
>
> would assure that each execution of printf would see an updated value.
>
> > If you properly use C11 mutexes, there is
> > absolutely no need for volatile.

>
> C11 mutexes (as are POSIX mutexes) are much too heavy machinery where a
> simple atomic would suffice. I think that atomics and the precise data
> consistency model are the real novelty in C11 (and C++1). That is to


That was my thinking. The POSIX mutex api is really kind of awkward,
and on Linux the underlying implementation is more complicated than it
has to be. Currently I'm developing on x86_64 and x86, and I chose to
use "lock incl %0" and then inspect the result to detect collisions.
It is obviously very fast, and I can control how long a thread will
spin on the lock before sleeping. I have yet to investigate whether I
need to use a different instruction for the 64-bit arch.

A compiler supported atomic type would allow the removal of the
minimal inline asm that I'm using, but I can keep it to preserve some
backward compatibility with older systems.

> provide a possibility of communicating safely between different threads
> (and with signal handlers) without relying on OS support (or almost).


One potential application for non-mutex locking structures occurs in
some virtualized environments. Under the Xen hypervisor, it is
possible to share virtual memory segments between guest domains. The
facility is called 'grant pages', and looks a little like a SYSV
shared memory segment to the application. With such a memory window,
a ring buffer (or equivalent algorithm) can allow inter-domain
communications without any system calls. The same goes, of course,
for a ring-buffer instantiated in SYSV shared memory, but that is
limited to communications between processes on the same host.
Compared to TCP/IP IPC, this should greatly improve the available IPC
bandwidth among virtualized hosts on a multi-core platform.

I haven't yet got to the point of integrating support for Xen in any
of my code, but it's on my todo list.


Regards,

Uncle Steve

--
The moon has never been closer.

 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      07-07-2012
On 7/6/2012 2:33 PM, Uncle Steve wrote:
> On Fri, Jul 06, 2012 at 06:11:28PM -0400, Eric Sosman wrote:
>> [...]
>> Although the latest "C11" Standard adds some multi-threading
>> support, [...]
>>
>> [...]I suggest you visit comp.programming.threads,
>> a newsgroup devoted to multi-threading issues. There you will learn
>> that `volatile' is neither necessary *nor* sufficient in connection
>> with variables shared between threads. [...]

>
> Is there are C standard threading framework?


See above.

> Threaded code is a de-facto reality in today's multi-core environment.
> Save for the embedded sector, most systems will run threads in
> parallel, and that is that. C has to recognize this watershed moment
> in the refinement of the language.


See above.

> What is it about the volatile attribute that makes it
> insufficient in your mind to the problem presented by threaded code?


"Then Kolokolo Bird said, with a mournful cry, 'Go to the banks of
the great grey-green, greasy Limpopo River -- er, that is, the G,G-G,G
comp.programming.threads newsgroup -- all set about with fever-trees,
and find out.'"

By "go," I mean "go away," as in "Don't continue this thread in
comp.lang.c unless you specifically wish to discuss the threading
features of C11." Follow-ups set.

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)d


 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      07-07-2012
On 7/7/2012 5:12 AM, Uncle Steve wrote:
> On Sat, Jul 07, 2012 at 08:16:53AM -0400, Eric Sosman wrote:
>> On 7/6/2012 2:33 PM, Uncle Steve wrote:
>>> On Fri, Jul 06, 2012 at 06:11:28PM -0400, Eric Sosman wrote:
>>>> [...]
>>>> Although the latest "C11" Standard adds some multi-threading
>>>> support, [...]
>>>>
>>>> [...]I suggest you visit comp.programming.threads,
>>>> a newsgroup devoted to multi-threading issues. There you will learn
>>>> that `volatile' is neither necessary *nor* sufficient in connection
>>>> with variables shared between threads. [...]
>>>
>>> Is there are C standard threading framework?

>>
>> See above.
>>
>>> Threaded code is a de-facto reality in today's multi-core environment.
>>> Save for the embedded sector, most systems will run threads in
>>> parallel, and that is that. C has to recognize this watershed moment
>>> in the refinement of the language.

>>
>> See above.
>>
>>> What is it about the volatile attribute that makes it
>>> insufficient in your mind to the problem presented by threaded code?

>>
>> "Then Kolokolo Bird said, with a mournful cry, 'Go to the banks of
>> the great grey-green, greasy Limpopo River -- er, that is, the G,G-G,G
>> comp.programming.threads newsgroup -- all set about with fever-trees,
>> and find out.'"
>>
>> By "go," I mean "go away," as in "Don't continue this thread in
>> comp.lang.c unless you specifically wish to discuss the threading
>> features of C11." Follow-ups set.

>
> Your message excells as an example of myopic religious orthodoxy. I'm
> not actually suggesting that there should be changes to the standard,
> so I don't quite understand why you seem so threatened.


When you ask (somewhat incoherently) "Is there are C standard
threading framework," which part of

THE LATEST "C11" STANDARD ADDS SOME MULTI-THREADING SUPPORT

are you having trouble understanding?

C11's threading support is on-topic here in comp.lang.c -- but
you've indicated that you're not interested in C11 threads and in fact
are using Pthreads instead. Pthreads is off-topic here, so please help
reduce the noise by removing the discussion to comp.programming.threads
which "excells" [sic] on that topic.

--
Eric Sosman
(E-Mail Removed)d


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
"Try:" which only encompasses head of compound statement Jameson.Quinn@gmail.com Python 9 08-29-2007 12:58 AM
sizeof(aStruct) returns fault number nass C++ 2 09-22-2006 03:24 PM
Applicability KB 831138: app that uses WebRequest has OutOfMemoryE =?Utf-8?B?dmVjb3pvQG9ubGluZS5ub3NwYW0=?= ASP .Net 9 01-05-2006 08:50 PM
wired / wireless network mixture or not ? ReceT Wireless Networking 3 07-12-2004 02:54 AM
gaussian mixture? GBartgo C++ 2 11-02-2003 12:10 AM



Advertisments