Minimum VC++ for Multi-Core?  
Author Message
coughlla





PostPosted: Thu May 17 09:52:51 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core?

I am using VC++ 6.0. My most "thread intensive" app does not run with
multi-core enabled in the P-4 Intel motherboard systems we use. Always need
to set BIOS to enable single core.

What platform or service pack do I need to take advantage of multi-core
technology?

Thanks
Tom Salicos

Visual Studio117  
 
 
MrAsm





PostPosted: Thu May 17 09:52:51 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? On Thu, 17 May 2007 07:22:49 -0600, "Tom Salicos"


>I am using VC++ 6.0. My most "thread intensive" app does not run with
>multi-core enabled in the P-4 Intel motherboard systems we use.

>What platform or service pack do I need to take advantage of multi-core
>technology?

Maybe you should move to Visual Studio 2005?

MrAsm
 
 
Scott





PostPosted: Thu May 17 10:17:02 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core?
> I am using VC++ 6.0. My most "thread intensive" app does not run with
> multi-core enabled in the P-4 Intel motherboard systems we use. Always need
> to set BIOS to enable single core.
>
> What platform or service pack do I need to take advantage of multi-core
> technology?

Taking advantage of multi-core technology has nothing to do with which
version of VC++ you are using. If you have multiple threads they will
take advantage of multi-cores. Conclusion: You have a threading bug
that only happens when executing on multiple cores. (This is not uncommon.)

--
Scott McPhillips [MVP VC++]

 
 
David





PostPosted: Thu May 17 10:18:47 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core?


> On Thu, 17 May 2007 07:22:49 -0600, "Tom Salicos"

>
>>I am using VC++ 6.0. My most "thread intensive" app does not run with
>>multi-core enabled in the P-4 Intel motherboard systems we use.
>
>>What platform or service pack do I need to take advantage of multi-core
>>technology?
>
> Maybe you should move to Visual Studio 2005?
>


That's a viable alternative, but if the app is multi-threaded properly, it
shouldn't matter if the system is multi-core or not, or what version of
Visual Studio is used to build it. There might be something wrong with
synchronization in the program's threads that manifests only on true
multi-proc machines.

-- David


 
 
Joseph





PostPosted: Thu May 17 11:09:24 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? Multicore support is irrelevant. VS6 supports it just fine. Multicore support, as you
observed, is set in the BIOS. The compiler and runtime have nothing to do with this.

I was writing multiprocessor apps in VS6 back when it was new, and they work just fine. No
service packs are required to achieve this (although you should be using VS6 SP5 just for
all the bug fixes you get)

Multicore capability cannot be enabled or disabled from an application because it is a
property of the BIOS/boot time configuration. Therefore, the compiler, runtime, etc. are
completely irrelevant to the issue.

I wrote multiprocessor apps in VS6 that ran just fine under NT4.

How are you determining that your app "does not run" on multiple processors?
joe



>I am using VC++ 6.0. My most "thread intensive" app does not run with
>multi-core enabled in the P-4 Intel motherboard systems we use. Always need
>to set BIOS to enable single core.
>
>What platform or service pack do I need to take advantage of multi-core
>technology?
>
>Thanks
>Tom Salicos
>
Joseph M. Newcomer [MVP]

Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
 
 
Joseph





PostPosted: Thu May 17 11:15:04 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? Since he said

> My most "thread intensive" app does not run with multi-core enabled

I presume that the code does not appear to be taking advantage of the multicore
capability. Had it been failing, or giving erroneous results, access faults, or asserts,
I assumed that the question would have explicitly said that it had errors.

Of course, if the question really should have been "my program does not run correctly when
multicore capability is enabled", then the obvious answer is the one you gave, "Your
program is wrong. You will have to fix it". In that case the program has *always* been
wrong, and the only reason it gives the illusion of working correctly in single-processor
mode is that the bugs are not being hit. Therefore, there is no option other than fixing
all the threading errors it has always had.

Note that VS6 works just fine for multithreaded applications, providing the program is
written correctly. Moving an incorrect program to VS2005 means that the program is still
incorrect, and will still not work.
joe

On Thu, 17 May 2007 11:16:55 -0400, "Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp>



>> I am using VC++ 6.0. My most "thread intensive" app does not run with
>> multi-core enabled in the P-4 Intel motherboard systems we use. Always need
>> to set BIOS to enable single core.
>>
>> What platform or service pack do I need to take advantage of multi-core
>> technology?
>
>Taking advantage of multi-core technology has nothing to do with which
>version of VC++ you are using. If you have multiple threads they will
>take advantage of multi-cores. Conclusion: You have a threading bug
>that only happens when executing on multiple cores. (This is not uncommon.)
Joseph M. Newcomer [MVP]

Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
 
 
Michael





PostPosted: Thu May 17 11:18:03 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core?



> > I am using VC++ 6.0. My most "thread intensive" app does not run with
> > multi-core enabled in the P-4 Intel motherboard systems we use. Always
need
> > to set BIOS to enable single core.
> >
> > What platform or service pack do I need to take advantage of multi-core
> > technology?
>
> Taking advantage of multi-core technology has nothing to do with which
> version of VC++ you are using. If you have multiple threads they will
> take advantage of multi-cores. Conclusion: You have a threading bug
> that only happens when executing on multiple cores. (This is not
uncommon.)
>
> --
> Scott McPhillips [MVP VC++]
>

I totally agree. VC6.0 produces perfectly acceptable programs for
multi-core machines. If the OP's program doesn't run on one, then there's a
threading bug.

Many threading bugs only manifest themsleves on multicore machines, which
might explain why you haven't seen it before.

Mike


 
 
Tom





PostPosted: Thu May 17 11:21:43 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? Perhaps you could post a bit of your threading code or the error messages
you are seeing? The consensus seems to be that the software shouldn't make
a difference unless there are some bugs lurking in there somewhere.

Tom



>I am using VC++ 6.0. My most "thread intensive" app does not run with
>multi-core enabled in the P-4 Intel motherboard systems we use. Always
>need to set BIOS to enable single core.
>
> What platform or service pack do I need to take advantage of multi-core
> technology?
>
> Thanks
> Tom Salicos
>
>

 
 
Joseph





PostPosted: Thu May 17 14:07:33 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? As I tell my driver students, "if you haven't tested your driver on a true multiprocessor,
it is still pre-alpha code, no matter what the release schedule claims"
joe

On Thu, 17 May 2007 09:18:03 -0700, "Michael K. O'Neill"


>



>> > I am using VC++ 6.0. My most "thread intensive" app does not run with
>> > multi-core enabled in the P-4 Intel motherboard systems we use. Always
>need
>> > to set BIOS to enable single core.
>> >
>> > What platform or service pack do I need to take advantage of multi-core
>> > technology?
>>
>> Taking advantage of multi-core technology has nothing to do with which
>> version of VC++ you are using. If you have multiple threads they will
>> take advantage of multi-cores. Conclusion: You have a threading bug
>> that only happens when executing on multiple cores. (This is not
>uncommon.)
>>
>> --
>> Scott McPhillips [MVP VC++]
>>
>
>I totally agree. VC6.0 produces perfectly acceptable programs for
>multi-core machines. If the OP's program doesn't run on one, then there's a
>threading bug.
>
>Many threading bugs only manifest themsleves on multicore machines, which
>might explain why you haven't seen it before.
>
>Mike
>
Joseph M. Newcomer [MVP]

Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
 
 
Tom





PostPosted: Thu May 17 15:41:32 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core?


> Multicore support is irrelevant. VS6 supports it just fine. Multicore
> support, as you
> observed, is set in the BIOS. The compiler and runtime have nothing to do
> with this.
>
> I was writing multiprocessor apps in VS6 back when it was new, and they
> work just fine. No
> service packs are required to achieve this (although you should be using
> VS6 SP5 just for
> all the bug fixes you get)
>
> Multicore capability cannot be enabled or disabled from an application
> because it is a
> property of the BIOS/boot time configuration. Therefore, the compiler,
> runtime, etc. are
> completely irrelevant to the issue.
>
> I wrote multiprocessor apps in VS6 that ran just fine under NT4.
>
> How are you determining that your app "does not run" on multiple
> processors?
> joe
>


>
>>I am using VC++ 6.0. My most "thread intensive" app does not run with
>>multi-core enabled in the P-4 Intel motherboard systems we use. Always
>>need
>>to set BIOS to enable single core.
>>
>>What platform or service pack do I need to take advantage of multi-core
>>technology?
>>
>>Thanks
>>Tom Salicos
>>
> Joseph M. Newcomer [MVP]

> Web: http://www.flounder.com



I made the ASSumption that I needed something different because disabling
multi-core stopped my problem. My bad. The offending app is based on the
demo program "AsyncClientServer" demo
http://support.microsoft.com/kb/192570 and seemingly runs without a hitch.
The client side and server side are split between two of our systems. The
client side runs on WinXP Pro and has the problem. If it runs at all, it is
sluggish. Usually it "crashes" immediately an the error is (paraphrased)
"Application requested termination in an abnormal fashion". Does that tell
me anything?

Now that I know it's me, I'll start troubleshooting.

Thanks

Tom Salicos








> MVP Tips: http://www.flounder.com/mvp_tips.htm


 
 
MrAsm





PostPosted: Thu May 17 16:54:25 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? On Thu, 17 May 2007 12:09:24 -0400, Joseph M. Newcomer


>I wrote multiprocessor apps in VS6 that ran just fine under NT4.

I thought that VS2005 (I don't have it) had some kind of extensions to
better support multiprocessors or multi-core architectures.

Of course you're right when you say that if the program has bugs in
VS6 then moving it to VS2005 does not "automagically" :) remove the
bugs :)

MrAsm
 
 
Michael





PostPosted: Thu May 17 17:38:00 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? >
> I made the ASSumption that I needed something different because disabling
> multi-core stopped my problem. My bad. The offending app is based on the
> demo program "AsyncClientServer" demo
> http://support.microsoft.com/kb/192570 and seemingly runs without a hitch.
> The client side and server side are split between two of our systems. The
> client side runs on WinXP Pro and has the problem. If it runs at all, it
is
> sluggish. Usually it "crashes" immediately an the error is (paraphrased)
> "Application requested termination in an abnormal fashion". Does that
tell
> me anything?
>
> Now that I know it's me, I'll start troubleshooting.
>
> Thanks
>
> Tom Salicos
>
>

It's not you (at least not completely).

KB 192570 is one of the most maligned samples out there, and is truly
shameful coding on Microsoft's part.

Joseph Newcomer has an entire article explaining how bad it is: "A Rewrite
of KB192570: An MFC Asynchronous Socket Example Done Right" at
http://www.flounder.com/kb192570.htm

His article also provides corrected code.

Mike


 
 
Tom





PostPosted: Thu May 17 17:41:05 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? Actually, every program I've moved to VS2005 has had some flaws revealed
that I've ended up fixing. I'm not sure they were all bugs, but some of
them were time bombs. The newer compiler has way better warnings.

Tom



>
> I thought that VS2005 (I don't have it) had some kind of extensions to
> better support multiprocessors or multi-core architectures.
>
> Of course you're right when you say that if the program has bugs in
> VS6 then moving it to VS2005 does not "automagically" :) remove the
> bugs :)
>
> MrAsm

 
 
Joseph





PostPosted: Fri May 18 00:07:03 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? It does, but they are largely irrelevant. It isn't VS2005, it is the Platform SDK that
comes with it, and it adds support for the new multicore NUMA-aware APIs supported in
Vista.
joe



>On Thu, 17 May 2007 12:09:24 -0400, Joseph M. Newcomer

>
>>I wrote multiprocessor apps in VS6 that ran just fine under NT4.
>
>I thought that VS2005 (I don't have it) had some kind of extensions to
>better support multiprocessors or multi-core architectures.
>
>Of course you're right when you say that if the program has bugs in
>VS6 then moving it to VS2005 does not "automagically" :) remove the
>bugs :)
>
>MrAsm
Joseph M. Newcomer [MVP]

Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
 
 
Joseph





PostPosted: Fri May 18 00:05:54 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? That particular example is one of the most egregiously poor examples ever written, since
it gets sockets wrong, threading wrong, and synchronization wrong. It is also not
Unicode-aware or platform-independent, and it gets the fundamental interfaces to messaging
wrong. It exhibits varioius aspects of extremely poor programming style, including an
complete misunderstanding of the role of stdafx.h, the C++ language, abstraction,
implementation, and fundamental good coding practice. Other than that, there's nothing
wrong with it.

See my rewrite of this horrendous article on

http://www.flounder.com/kb192570.htm

I would not trust that KB article code as far as I could heave a 1970s mainframe. Not to
put too fine a point on it, it is almost entirely crap. My code compiles and runs,
correctly, on Win32, Win64, in both ANSI and Unicode modes, and uses UTF-8 as its
interchange format.

There is nothing you can salvage in that code. I tried, and there are so few lines in
common that it is clear that this code should be removed from the MSDN (I have already
submitted this as a formal request: rewrite it, use my example, or get rid of it
entirely--code this bad must not be allowed to persist)
joe


>


>> Multicore support is irrelevant. VS6 supports it just fine. Multicore
>> support, as you
>> observed, is set in the BIOS. The compiler and runtime have nothing to do
>> with this.
>>
>> I was writing multiprocessor apps in VS6 back when it was new, and they
>> work just fine. No
>> service packs are required to achieve this (although you should be using
>> VS6 SP5 just for
>> all the bug fixes you get)
>>
>> Multicore capability cannot be enabled or disabled from an application
>> because it is a
>> property of the BIOS/boot time configuration. Therefore, the compiler,
>> runtime, etc. are
>> completely irrelevant to the issue.
>>
>> I wrote multiprocessor apps in VS6 that ran just fine under NT4.
>>
>> How are you determining that your app "does not run" on multiple
>> processors?
>> joe
>>


>>
>>>I am using VC++ 6.0. My most "thread intensive" app does not run with
>>>multi-core enabled in the P-4 Intel motherboard systems we use. Always
>>>need
>>>to set BIOS to enable single core.
>>>
>>>What platform or service pack do I need to take advantage of multi-core
>>>technology?
>>>
>>>Thanks
>>>Tom Salicos
>>>
>> Joseph M. Newcomer [MVP]

>> Web: http://www.flounder.com
>
>
>
>I made the ASSumption that I needed something different because disabling
>multi-core stopped my problem. My bad. The offending app is based on the
>demo program "AsyncClientServer" demo
>http://support.microsoft.com/kb/192570 and seemingly runs without a hitch.
>The client side and server side are split between two of our systems. The
>client side runs on WinXP Pro and has the problem. If it runs at all, it is
>sluggish. Usually it "crashes" immediately an the error is (paraphrased)
>"Application requested termination in an abnormal fashion". Does that tell
>me anything?
>
>Now that I know it's me, I'll start troubleshooting.
>
>Thanks
>
>Tom Salicos
>
>
>
>
>
>
>
>
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>
Joseph M. Newcomer [MVP]

Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
 
 
Ismo





PostPosted: Fri May 18 05:55:30 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? ---snip---

Wasn't there a bug in STL (the one shipped with compiler)
strings in VC6 which manifests much more often on multicore
than single core ?

Something to do with sharing of strings between instances.

There was some tricks to turn it off.

ismo
 
 
MrAsm





PostPosted: Fri May 18 08:56:55 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? On Thu, 17 May 2007 15:41:05 -0700, "Tom Serface"


>Actually, every program I've moved to VS2005 has had some flaws revealed
>that I've ended up fixing. I'm not sure they were all bugs, but some of
>them were time bombs. The newer compiler has way better warnings.

Hi Tom,

I agree that compiler's warnings are our friends.

I wonder what are the "time bombs" that VS2005 warned you about.
You wrote that they were not bugs, so I assume you are not referring
to e.g. array indexes out of bounds (e.g. int v[100]; v[100] = ...) -
also because using a C++ well designed array class like MFC CArray or
std::vector we can have safe bounds checking.

Thanks,
MrAsm
 
 
Joseph





PostPosted: Fri May 18 09:03:49 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? Since STL is not thread-safe, it seems unlikely that earlier versions are going to have
multithreaded-related bugs different from the same bugs in the VS2005 version of STL.
joe


>---snip---
>
>Wasn't there a bug in STL (the one shipped with compiler)
>strings in VC6 which manifests much more often on multicore
>than single core ?
>
>Something to do with sharing of strings between instances.
>
>There was some tricks to turn it off.
>
>ismo
Joseph M. Newcomer [MVP]

Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
 
 
MrAsm





PostPosted: Fri May 18 09:44:02 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? On Fri, 18 May 2007 13:55:30 +0300, Ismo Salonen


>---snip---
>
>Wasn't there a bug in STL (the one shipped with compiler)
>strings in VC6 which manifests much more often on multicore
>than single core ?

Is that?

http://support.microsoft.com/kb/813810

MrAsm
 
 
MrAsm





PostPosted: Fri May 18 09:49:11 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? On Fri, 18 May 2007 13:55:30 +0300, Ismo Salonen



>Wasn't there a bug in STL (the one shipped with compiler)
>strings in VC6

BTW: if one wants to "safely" use STL in VC6, he should use STLport or
apply Dinkumware's fixes:

http://www.dinkumware.com/vc_fixes.html

MrAsm
 
 
Joseph





PostPosted: Fri May 18 12:40:23 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? Well, since strings are not thread-safe, this just says that strings are not thread-safe.
I'm amazed that this is the only bug that was reported, since it arises because of the use
of a std::string by two threads without synchronization. Since it is a reference-count
problem, it is true that it will most likely show up on multiprocessors, but in reading
the article, it sounds like just plain unsafe use of an object that is not thread-safe was
not supported.

Notice that the article says VS.NET 2003 is "thread-safe for [this] problem" but I
remember some months ago some twit ranting about not ever using MFC's CString "because it
is not thread-safe" and he would only use STL. It was clearly the ranting of an amateur,
because I posted just one of the std::string routines and asked him to show where it
provided thread-safe synchronization (and that was from VS.NET 2003). Needless to say, it
doesn't provide such capability.

I can't actually find anything in the implementation of the std::string or basic_string
classes that indicates that there is any low-level synchronization. I'm not sure where
this is being done but it did not immediately present itself.
joe



>On Fri, 18 May 2007 13:55:30 +0300, Ismo Salonen

>
>>---snip---
>>
>>Wasn't there a bug in STL (the one shipped with compiler)
>>strings in VC6 which manifests much more often on multicore
>>than single core ?
>
>Is that?
>
>http://support.microsoft.com/kb/813810
>
>MrAsm
Joseph M. Newcomer [MVP]

Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
 
 
MrAsm





PostPosted: Fri May 18 14:21:24 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? On Fri, 18 May 2007 13:40:23 -0400, Joseph M. Newcomer


>Notice that the article says VS.NET 2003 is "thread-safe for [this] problem" but I
>remember some months ago some twit ranting about not ever using MFC's CString "because it
>is not thread-safe" and he would only use STL. It was clearly the ranting of an amateur,
>because I posted just one of the std::string routines and asked him to show where it
>provided thread-safe synchronization (and that was from VS.NET 2003). Needless to say, it
>doesn't provide such capability.

Joe: so, if we want thread-safety for STL containers and strings, is
it better to use some "external" method (not built in STL) like
Single-Writer-Multiple-Readers threading approach?
(It was also described in a book by Jeff Richter, maybe it was
"Advanced Windows programming", if I recall correctly).

MrAsm

 
 
Geeky





PostPosted: Fri May 18 16:39:07 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? HI Joe,

Nice article on threaded sockets!

I just wanted to point out that Microsoft has a different view of TCP
port usage than the rest of the world does; and as a result your usage
of the TCP/IP port 0xC001 to accept connections could fail because
this is in the range of epehmeral ports which are dynamically assigned
by the OS for temporary connections.

By default the ephemeral range is split from 1025 to 5000 (default for
MaxUserPort) and from 49152 to 65535. You can also reserve ports so
that they are excluded from ephemeral assignment.

The reason the Microsoft guy picked the "random port" around 10000 was
because he knew it was NOT in the ephemeral range.

See this technical article for more explanation:
http://www.microsoft.com/technet/community/columns/cableguy/cg1205.mspx

Oracle, for example, reccomends changing MaxUserPort to 13000, then to
set ReservedPorts to 1024-8000 leaving 8001 to 13000 for ephemeral
use.

XP-professional actually starts using ephemeral ports at 3000 to avoid
painful IANA usage collisions.

Your choice of 0xC001 would probably never cause a problem because the
machine would have to plough though all of the ephemeral ports in the
low range first, but to be thorough, you should add 49153-49153 to the
ReservedPorts in the registry.

On the other hand, the machine could be configured so that MaxUserPort
is set to 49152 in which case your port would be the first one to be
hit. It pays to examine the machine's configuration on setup and add
your service's port range to the reserved list in the registry.

Thanks again for the great article,
-Kurt

On Fri, 18 May 2007 01:05:54 -0400, Joseph M. Newcomer


>That particular example is one of the most egregiously poor examples ever written, since
>it gets sockets wrong, threading wrong, and synchronization wrong. It is also not
>Unicode-aware or platform-independent, and it gets the fundamental interfaces to messaging
>wrong. It exhibits varioius aspects of extremely poor programming style, including an
>complete misunderstanding of the role of stdafx.h, the C++ language, abstraction,
>implementation, and fundamental good coding practice. Other than that, there's nothing
>wrong with it.
>
>See my rewrite of this horrendous article on
>
>http://www.flounder.com/kb192570.htm
>
>I would not trust that KB article code as far as I could heave a 1970s mainframe. Not to
>put too fine a point on it, it is almost entirely crap. My code compiles and runs,
>correctly, on Win32, Win64, in both ANSI and Unicode modes, and uses UTF-8 as its
>interchange format.
>
>There is nothing you can salvage in that code. I tried, and there are so few lines in
>common that it is clear that this code should be removed from the MSDN (I have already
>submitted this as a formal request: rewrite it, use my example, or get rid of it
>entirely--code this bad must not be allowed to persist)
> joe

>
>>


>>> Multicore support is irrelevant. VS6 supports it just fine. Multicore
>>> support, as you
>>> observed, is set in the BIOS. The compiler and runtime have nothing to do
>>> with this.
>>>
>>> I was writing multiprocessor apps in VS6 back when it was new, and they
>>> work just fine. No
>>> service packs are required to achieve this (although you should be using
>>> VS6 SP5 just for
>>> all the bug fixes you get)
>>>
>>> Multicore capability cannot be enabled or disabled from an application
>>> because it is a
>>> property of the BIOS/boot time configuration. Therefore, the compiler,
>>> runtime, etc. are
>>> completely irrelevant to the issue.
>>>
>>> I wrote multiprocessor apps in VS6 that ran just fine under NT4.
>>>
>>> How are you determining that your app "does not run" on multiple
>>> processors?
>>> joe
>>>


>>>
>>>>I am using VC++ 6.0. My most "thread intensive" app does not run with
>>>>multi-core enabled in the P-4 Intel motherboard systems we use. Always
>>>>need
>>>>to set BIOS to enable single core.
>>>>
>>>>What platform or service pack do I need to take advantage of multi-core
>>>>technology?
>>>>
>>>>Thanks
>>>>Tom Salicos
>>>>
>>> Joseph M. Newcomer [MVP]

>>> Web: http://www.flounder.com
>>
>>
>>
>>I made the ASSumption that I needed something different because disabling
>>multi-core stopped my problem. My bad. The offending app is based on the
>>demo program "AsyncClientServer" demo
>>http://support.microsoft.com/kb/192570 and seemingly runs without a hitch.
>>The client side and server side are split between two of our systems. The
>>client side runs on WinXP Pro and has the problem. If it runs at all, it is
>>sluggish. Usually it "crashes" immediately an the error is (paraphrased)
>>"Application requested termination in an abnormal fashion". Does that tell
>>me anything?
>>
>>Now that I know it's me, I'll start troubleshooting.
>>
>>Thanks
>>
>>Tom Salicos
>>
>>
>>
>>
>>
>>
>>
>>
>>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>>
>Joseph M. Newcomer [MVP]

>Web: http://www.flounder.com
>MVP Tips: http://www.flounder.com/mvp_tips.htm
 
 
Joseph





PostPosted: Fri May 18 22:47:57 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? No, it is actually in the area of "unassigned ports". But it is really important, before
choosing an apparent random number for a port, to at least look at the existing IANA
assignments. For a product, you can apply (no charge!) for a port number. Note that I am
registered for 5428, which is actually one of my clients.

10000 and beyond are also in the Registred port area, and ports up to 0xBFFF have many
assignments in the list. Therefore, it is largely inappropriate to use any ports in this
range because of the potential for current or future conflicts with actual registered
ports.
joe



>HI Joe,
>
>Nice article on threaded sockets!
>
>I just wanted to point out that Microsoft has a different view of TCP
>port usage than the rest of the world does; and as a result your usage
>of the TCP/IP port 0xC001 to accept connections could fail because
>this is in the range of epehmeral ports which are dynamically assigned
>by the OS for temporary connections.
>
>By default the ephemeral range is split from 1025 to 5000 (default for
>MaxUserPort) and from 49152 to 65535. You can also reserve ports so
>that they are excluded from ephemeral assignment.
>
>The reason the Microsoft guy picked the "random port" around 10000 was
>because he knew it was NOT in the ephemeral range.
>
>See this technical article for more explanation:
>http://www.microsoft.com/technet/community/columns/cableguy/cg1205.mspx
>
>Oracle, for example, reccomends changing MaxUserPort to 13000, then to
>set ReservedPorts to 1024-8000 leaving 8001 to 13000 for ephemeral
>use.
>
>XP-professional actually starts using ephemeral ports at 3000 to avoid
>painful IANA usage collisions.
>
>Your choice of 0xC001 would probably never cause a problem because the
>machine would have to plough though all of the ephemeral ports in the
>low range first, but to be thorough, you should add 49153-49153 to the
>ReservedPorts in the registry.
>
>On the other hand, the machine could be configured so that MaxUserPort
>is set to 49152 in which case your port would be the first one to be
>hit. It pays to examine the machine's configuration on setup and add
>your service's port range to the reserved list in the registry.
>
>Thanks again for the great article,
>-Kurt
>
>On Fri, 18 May 2007 01:05:54 -0400, Joseph M. Newcomer

>
>>That particular example is one of the most egregiously poor examples ever written, since
>>it gets sockets wrong, threading wrong, and synchronization wrong. It is also not
>>Unicode-aware or platform-independent, and it gets the fundamental interfaces to messaging
>>wrong. It exhibits varioius aspects of extremely poor programming style, including an
>>complete misunderstanding of the role of stdafx.h, the C++ language, abstraction,
>>implementation, and fundamental good coding practice. Other than that, there's nothing
>>wrong with it.
>>
>>See my rewrite of this horrendous article on
>>
>>http://www.flounder.com/kb192570.htm
>>
>>I would not trust that KB article code as far as I could heave a 1970s mainframe. Not to
>>put too fine a point on it, it is almost entirely crap. My code compiles and runs,
>>correctly, on Win32, Win64, in both ANSI and Unicode modes, and uses UTF-8 as its
>>interchange format.
>>
>>There is nothing you can salvage in that code. I tried, and there are so few lines in
>>common that it is clear that this code should be removed from the MSDN (I have already
>>submitted this as a formal request: rewrite it, use my example, or get rid of it
>>entirely--code this bad must not be allowed to persist)
>> joe

>>
>>>


>>>> Multicore support is irrelevant. VS6 supports it just fine. Multicore
>>>> support, as you
>>>> observed, is set in the BIOS. The compiler and runtime have nothing to do
>>>> with this.
>>>>
>>>> I was writing multiprocessor apps in VS6 back when it was new, and they
>>>> work just fine. No
>>>> service packs are required to achieve this (although you should be using
>>>> VS6 SP5 just for
>>>> all the bug fixes you get)
>>>>
>>>> Multicore capability cannot be enabled or disabled from an application
>>>> because it is a
>>>> property of the BIOS/boot time configuration. Therefore, the compiler,
>>>> runtime, etc. are
>>>> completely irrelevant to the issue.
>>>>
>>>> I wrote multiprocessor apps in VS6 that ran just fine under NT4.
>>>>
>>>> How are you determining that your app "does not run" on multiple
>>>> processors?
>>>> joe
>>>>


>>>>
>>>>>I am using VC++ 6.0. My most "thread intensive" app does not run with
>>>>>multi-core enabled in the P-4 Intel motherboard systems we use. Always
>>>>>need
>>>>>to set BIOS to enable single core.
>>>>>
>>>>>What platform or service pack do I need to take advantage of multi-core
>>>>>technology?
>>>>>
>>>>>Thanks
>>>>>Tom Salicos
>>>>>
>>>> Joseph M. Newcomer [MVP]

>>>> Web: http://www.flounder.com
>>>
>>>
>>>
>>>I made the ASSumption that I needed something different because disabling
>>>multi-core stopped my problem. My bad. The offending app is based on the
>>>demo program "AsyncClientServer" demo
>>>http://support.microsoft.com/kb/192570 and seemingly runs without a hitch.
>>>The client side and server side are split between two of our systems. The
>>>client side runs on WinXP Pro and has the problem. If it runs at all, it is
>>>sluggish. Usually it "crashes" immediately an the error is (paraphrased)
>>>"Application requested termination in an abnormal fashion". Does that tell
>>>me anything?
>>>
>>>Now that I know it's me, I'll start troubleshooting.
>>>
>>>Thanks
>>>
>>>Tom Salicos
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>>>
>>Joseph M. Newcomer [MVP]

>>Web: http://www.flounder.com
>>MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]

Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
 
 
Joseph





PostPosted: Fri May 18 23:13:13 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? If you want thread safety in STL you have to provide the synchronization yourself. By
whatever means are appropriate. Generally, you don't need to worry about
multiple-reader-single-writer unless you are having a performance problem that this
approach will solve. For STL objects, a CRITICAL_SECTION should suffice because it is
substantially faster than most other synchronization approaches. Richter's approach is
massively expensive because it uses both mutexes and semaphores, and it only works well if
there are long computations involving much reading, and occasional computations that
require writing. The computations that read or write have to be long enough that the
overheads of getting into and out of the locking is essentially irrelevant to the cost of
the computation. For simple objects like STL objects, where there is very little effort
involved in most computations, the cost of his solution compared to the exclusive-only
access of a CRITICAL_SECTION is exorbitant.

My own belief is that the best synchronization is no synchronization, by which I mean that
most code should be written so that the potential conflicts are handled without the need
to synchronize because data is not actually accessed by two or more threads. This is not
always possible, and "lock-free" algorithms are very tricky, but generally I use either
the "positive-handoff protcol", in which responsibility for an object is passed from
thread to thread but only one thread at a time can have responsibility for the object, or
the "central manager" technique, in which a data structure is managed by exactly one
thread and interthread communication is used to treat that thread as a "server" for the
object. Both of these techniques are essentially simpler to design and program than
locking protocols, and they are far more robust. They are also not prone to deadlock
problems either. Since they are easier to reason about, the extra overhead to design and
program them is justified (when I said "simpler" I did not mean "easier" in that you have
to think carefully about the design, but once it is set, it is hard to break. Robustness
under maintenance is a critical goal in multithreaded systems. So ultimately the outcome
is both simpler and easier, but it is not zero-cost.)
joe



>On Fri, 18 May 2007 13:40:23 -0400, Joseph M. Newcomer

>
>>Notice that the article says VS.NET 2003 is "thread-safe for [this] problem" but I
>>remember some months ago some twit ranting about not ever using MFC's CString "because it
>>is not thread-safe" and he would only use STL. It was clearly the ranting of an amateur,
>>because I posted just one of the std::string routines and asked him to show where it
>>provided thread-safe synchronization (and that was from VS.NET 2003). Needless to say, it
>>doesn't provide such capability.
>
>Joe: so, if we want thread-safety for STL containers and strings, is
>it better to use some "external" method (not built in STL) like
>Single-Writer-Multiple-Readers threading approach?
>(It was also described in a book by Jeff Richter, maybe it was
>"Advanced Windows programming", if I recall correctly).
>
>MrAsm
Joseph M. Newcomer [MVP]

Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
 
 
MrAsm





PostPosted: Sat May 19 04:41:33 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? On Sat, 19 May 2007 00:13:13 -0400, Joseph M. Newcomer


>If you want thread safety in STL you have to provide the synchronization yourself. By
>whatever means are appropriate. Generally, you don't need to worry about
>multiple-reader-single-writer unless you are having a performance problem that this
>approach will solve. For STL objects, a CRITICAL_SECTION should suffice because it is
>substantially faster than most other synchronization approaches. Richter's approach is
>massively expensive because it uses both mutexes and semaphores,
[...]

>My own belief is that the best synchronization is no synchronization, by which I mean that
[...]

Very clear and very interesting, as usual!

Thank you very much, Joe.

MrAsm
 
 
Tom





PostPosted: Sat May 19 09:01:51 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? Hi MrAsm,

For example, when I moved one project to 2005 it warned me that the older
versions of the str* functions were unsafe and being deprecated. I found a
couple of places that worked, but had conditions that could have gone out of
bounds. It also warned me about uninitialized variables in some places
where it hadn't before. One thing I really like is it no longer defaults to
int for functions that are not typed (I had 2 no typed by mistake). Things
like that.

Tom



> On Thu, 17 May 2007 15:41:05 -0700, "Tom Serface"

>
>>Actually, every program I've moved to VS2005 has had some flaws revealed
>>that I've ended up fixing. I'm not sure they were all bugs, but some of
>>them were time bombs. The newer compiler has way better warnings.
>
> Hi Tom,
>
> I agree that compiler's warnings are our friends.
>
> I wonder what are the "time bombs" that VS2005 warned you about.
> You wrote that they were not bugs, so I assume you are not referring
> to e.g. array indexes out of bounds (e.g. int v[100]; v[100] = ...) -
> also because using a C++ well designed array class like MFC CArray or
> std::vector we can have safe bounds checking.
>
> Thanks,
> MrAsm

 
 
MrAsm





PostPosted: Sat May 19 09:58:58 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? On Sat, 19 May 2007 07:01:51 -0700, "Tom Serface"


>For example, when I moved one project to 2005 it warned me that the older
>versions of the str* functions were unsafe and being deprecated.

>It also warned me about uninitialized variables in some places
>where it hadn't before.

>One thing I really like is it no longer defaults to
>int for functions that are not typed

Very good.
Thank you Tom.

MrAsm

 
 
Joseph





PostPosted: Sat May 19 10:28:51 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? In spite of the efforts to destroy the IDE, by contrast the attempts to make the compiler
more usable are excellent.

While I find very few errors I made even in VS4.2, some of the ones the VS2003 and VS2005
compilers find in my VS6 code are rather embarrassing...I just moved 120K lines from 4.2
to VS2005 and was not totally embarrassed. The whole operation took about two hours (the
client had never recompiled the code in ten years! But they wanted a Vista version...I'm
still wrestling with the manifest issues...is there any good documentation on manifests?
I've spent vastly more time on the manifest problem than the 4.2-to-VS2005 conversion!)

I'm taking the weekend off, will go fight manifests Monday.
joe



>Hi MrAsm,
>
>For example, when I moved one project to 2005 it warned me that the older
>versions of the str* functions were unsafe and being deprecated. I found a
>couple of places that worked, but had conditions that could have gone out of
>bounds. It also warned me about uninitialized variables in some places
>where it hadn't before. One thing I really like is it no longer defaults to
>int for functions that are not typed (I had 2 no typed by mistake). Things
>like that.
>
>Tom
>


>> On Thu, 17 May 2007 15:41:05 -0700, "Tom Serface"

>>
>>>Actually, every program I've moved to VS2005 has had some flaws revealed
>>>that I've ended up fixing. I'm not sure they were all bugs, but some of
>>>them were time bombs. The newer compiler has way better warnings.
>>
>> Hi Tom,
>>
>> I agree that compiler's warnings are our friends.
>>
>> I wonder what are the "time bombs" that VS2005 warned you about.
>> You wrote that they were not bugs, so I assume you are not referring
>> to e.g. array indexes out of bounds (e.g. int v[100]; v[100] = ...) -
>> also because using a C++ well designed array class like MFC CArray or
>> std::vector we can have safe bounds checking.
>>
>> Thanks,
>> MrAsm
Joseph M. Newcomer [MVP]

Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
 
 
Joseph





PostPosted: Sat May 19 10:31:38 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? But what was odd was that I didn't see any attempt in the VS.NET 2003 implementation to do
any synchronization at this level, either.
joe





>> Well, since strings are not thread-safe, this just says that strings
>> are not thread-safe. I'm amazed that this is the only bug that was
>> reported, since it arises because of the use of a std::string by two
>> threads without synchronization.
>
>There's more to it than that. The KB article is talking about a bug that
>arises when two threads each have their own copy of a std::string but
>(because of the COW implementation of strings in the rtl) these two
>"copies" actually share a buffer (and a reference count).
>
>This is not simply a matter of using a single string and failing to
>synchronize access to it from two threads, it is a matter of using two
>separate strings and the smoke-and-mirrors that optimizes their use of
>memory (in a manner that is supposed to be invisible to the user) failing
>to provide synchronization.
>
>In VS200x the implementation of std::string (and that of CString, too, BTW)
>uses a small-string optimization rather than shared buffers and COW,
>specifically to avoid such threading problems.
>
>Cheers,
> Daniel.
>
Joseph M. Newcomer [MVP]

Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
 
 
David





PostPosted: Sat May 19 10:57:09 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core?

> I'm
> still wrestling with the manifest issues...is there any good documentation
> on manifests?
> I've spent vastly more time on the manifest problem than the 4.2-to-VS2005
> conversion!)
>

Just search Google Groups... we've discussed manifests here so many times.
Bottom line is open the Project Properties and adjust the Manifests option;
if you have your own manifest, specify it there, otherwise it will ignore it
and use the generated option.

-- David


 
 
MrAsm





PostPosted: Sat May 19 11:02:12 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? On Sat, 19 May 2007 11:28:51 -0400, Joseph M. Newcomer


>In spite of the efforts to destroy the IDE, by contrast the attempts to make the compiler
>more usable are excellent.

Yes, I also remember reading your essay:

http://www.flounder.com/memory_damage.htm

where you wrote that the new C++ compiler does some very useful
security checkings like stack-frame checking.

And the new compiler is also more C++ compliant.

BTW: I think that developing a compiler (exspecially a C++ compiler -
being C++ a very complex language) it's a much harder job than
developing an IDE, so the C++ compiler guys in Microsoft must be very
talented people. I don't understand why they did the "hard job" of
writing a compiler very well, but the easier job of IDE development
worse.

>.I'm
>still wrestling with the manifest issues...is there any good documentation on manifests?
>I've spent vastly more time on the manifest problem than the 4.2-to-VS2005 conversion!)

I think that the real problem with manifests is lack of documentation;
the manifest technology may be a good solution against DLL-Hell, but
if it is undocumented or bad-documented, it's just useless IMHO.

Have a good week-end.

MrAsm
 
 
Doug





PostPosted: Sat May 19 11:33:36 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? On Sat, 19 May 2007 11:31:38 -0400, Joseph M. Newcomer



>


>>> Well, since strings are not thread-safe, this just says that strings
>>> are not thread-safe. I'm amazed that this is the only bug that was
>>> reported, since it arises because of the use of a std::string by two
>>> threads without synchronization.
>>
>>There's more to it than that. The KB article is talking about a bug that
>>arises when two threads each have their own copy of a std::string but
>>(because of the COW implementation of strings in the rtl) these two
>>"copies" actually share a buffer (and a reference count).

The C++ Standard requires that std::string::reference be an actual
reference instead of a class type, and this forbids COW. It does allow the
poor substitute early string implementations used, which I call
"copy-just-in-case", because it unshares the string merely upon producing a
non-const iterator or reference, just in case the string is ever written
through them.

>>This is not simply a matter of using a single string and failing to
>>synchronize access to it from two threads, it is a matter of using two
>>separate strings and the smoke-and-mirrors that optimizes their use of
>>memory (in a manner that is supposed to be invisible to the user) failing
>>to provide synchronization.
>>
>>In VS200x the implementation of std::string (and that of CString, too, BTW)
>>uses a small-string optimization rather than shared buffers and COW,
>>specifically to avoid such threading problems.

CString remains COW (real COW, that is).

>>Cheers,
>> Daniel.
>>
>But what was odd was that I didn't see any attempt in the VS.NET 2003 implementation to do
>any synchronization at this level, either.
> joe

What class and what level?

--
Doug Harrison
Visual C++ MVP
 
 
Doug





PostPosted: Sat May 19 11:58:21 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core?

>BTW: I think that developing a compiler (exspecially a C++ compiler -
>being C++ a very complex language) it's a much harder job than
>developing an IDE, so the C++ compiler guys in Microsoft must be very
>talented people. I don't understand why they did the "hard job" of
>writing a compiler very well, but the easier job of IDE development
>worse.

There is no "IDE Standard", nor is there a dragon book for IDEs (there are
books like "GUI Bloopers" and "The Design of Everyday Things", but nothing
specifically written for IDEs). This is not to say that writing the
compiler is any easier than you implied, but it is a more well-defined
problem, whose implementation quality is more easily measured, with 50
years of highly developed theory for implementers to study and apply. The
IDE suffered when they tried to fit the VC++ UI into the VS.NET 2002 mold;
prior to that, the VC++ IDE had always been separate from "Visual Studio".
Unfortunately, they didn't retain the VC6 features that made sense, such as
the ClassWizard.

--
Doug Harrison
Visual C++ MVP
 
 
Joseph





PostPosted: Sat May 19 19:48:02 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? Part of the problem is that they apparently gave "GUI Bloopers" to the IDE designer and he
mistook it for a "Best Patterns and Practices" book.

If you think this was done because the non-C++ stuff was great and isn't compatible with
C++, I find the IDE every bit as user-hostile when I'm writing C# code. The couple
excursions I did into VB convinced me that the IDE design for VB was pretty horrendous as
well.

The error was in redoing it in a fascist style that prevents users from having easy ways
to do things, in favor of a "uniform model" approach that is actually unusable. Modality
is wrong. We've known this for decades. So why was a fundamentally modeless interface
rewritten as a highly-modal interface? Perhaps naivite, perhaps incompetence. I'm not
sure which, but it was clear there was no oversight on this design by anyone who was
experienced in Human Computer Interface (HCI) issues.
joe




>
>>BTW: I think that developing a compiler (exspecially a C++ compiler -
>>being C++ a very complex language) it's a much harder job than
>>developing an IDE, so the C++ compiler guys in Microsoft must be very
>>talented people. I don't understand why they did the "hard job" of
>>writing a compiler very well, but the easier job of IDE development
>>worse.
>
>There is no "IDE Standard", nor is there a dragon book for IDEs (there are
>books like "GUI Bloopers" and "The Design of Everyday Things", but nothing
>specifically written for IDEs). This is not to say that writing the
>compiler is any easier than you implied, but it is a more well-defined
>problem, whose implementation quality is more easily measured, with 50
>years of highly developed theory for implementers to study and apply. The
>IDE suffered when they tried to fit the VC++ UI into the VS.NET 2002 mold;
>prior to that, the VC++ IDE had always been separate from "Visual Studio".
>Unfortunately, they didn't retain the VC6 features that made sense, such as
>the ClassWizard.
Joseph M. Newcomer [MVP]

Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
 
 
Joseph





PostPosted: Sat May 19 19:50:55 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? I searched std::string, std::basic_string<type>, the allocator functions, I did all kinds
of searches for Interlocked... anything, I read all kinds of code, and overall I spent
about an hour looking for COW code or any attempt to handle any form of synchronization
for any purpose whatsoever, and couldn't find any. This doesn't mean it isn't there, but
it certainly does not present itself in a meaningful fashion if it does exist.
joe



>On Sat, 19 May 2007 11:31:38 -0400, Joseph M. Newcomer

>

>>


>>>> Well, since strings are not thread-safe, this just says that strings
>>>> are not thread-safe. I'm amazed that this is the only bug that was
>>>> reported, since it arises because of the use of a std::string by two
>>>> threads without synchronization.
>>>
>>>There's more to it than that. The KB article is talking about a bug that
>>>arises when two threads each have their own copy of a std::string but
>>>(because of the COW implementation of strings in the rtl) these two
>>>"copies" actually share a buffer (and a reference count).
>
>The C++ Standard requires that std::string::reference be an actual
>reference instead of a class type, and this forbids COW. It does allow the
>poor substitute early string implementations used, which I call
>"copy-just-in-case", because it unshares the string merely upon producing a
>non-const iterator or reference, just in case the string is ever written
>through them.
>
>>>This is not simply a matter of using a single string and failing to
>>>synchronize access to it from two threads, it is a matter of using two
>>>separate strings and the smoke-and-mirrors that optimizes their use of
>>>memory (in a manner that is supposed to be invisible to the user) failing
>>>to provide synchronization.
>>>
>>>In VS200x the implementation of std::string (and that of CString, too, BTW)
>>>uses a small-string optimization rather than shared buffers and COW,
>>>specifically to avoid such threading problems.
>
>CString remains COW (real COW, that is).
>
>>>Cheers,
>>> Daniel.
>>>
>>But what was odd was that I didn't see any attempt in the VS.NET 2003 implementation to do
>>any synchronization at this level, either.
>> joe
>
>What class and what level?
Joseph M. Newcomer [MVP]

Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
 
 
Doug





PostPosted: Sat May 19 19:58:42 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? On Sat, 19 May 2007 20:50:55 -0400, Joseph M. Newcomer


>I searched std::string, std::basic_string<type>, the allocator functions, I did all kinds
>of searches for Interlocked... anything, I read all kinds of code, and overall I spent
>about an hour looking for COW code or any attempt to handle any form of synchronization
>for any purpose whatsoever, and couldn't find any. This doesn't mean it isn't there, but
>it certainly does not present itself in a meaningful fashion if it does exist.
> joe

If it isn't doing COW (or rather the poor imitation permitted by the C++
Standard), there's nothing to synchronize.

--
Doug Harrison
Visual C++ MVP
 
 
Doug





PostPosted: Sat May 19 21:10:58 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? On Sat, 19 May 2007 20:48:02 -0400, Joseph M. Newcomer


>Part of the problem is that they apparently gave "GUI Bloopers" to the IDE designer and he
>mistook it for a "Best Patterns and Practices" book.

That would explain a lot. <g>

>If you think this was done because the non-C++ stuff was great and isn't compatible with
>C++, I find the IDE every bit as user-hostile when I'm writing C# code. The couple
>excursions I did into VB convinced me that the IDE design for VB was pretty horrendous as
>well.
>
>The error was in redoing it in a fascist style that prevents users from having easy ways
>to do things, in favor of a "uniform model" approach that is actually unusable. Modality
>is wrong. We've known this for decades. So why was a fundamentally modeless interface
>rewritten as a highly-modal interface? Perhaps naivite, perhaps incompetence. I'm not
>sure which, but it was clear there was no oversight on this design by anyone who was
>experienced in Human Computer Interface (HCI) issues.
> joe

But the new, separate "Event Handler Wizard" and "Add Member Variable
Wizard" now greet you with a friendly "Welcome" message. The sad thing is,
there's nothing about the IDE that requires them to only let you modify one
thing per invocation, nor is there anything that requires the "Event
Handler Wizard" to take you away from the dialog editor and dump you into a
code window. Similarly, adding a handler through the "Control Events"
button in the Properties pane does not have to initiate a script that dumps
you into the code window, requiring you to navigate back to the dialog
editor and click the "Control Events" button again. There's nothing fatal
here that I can see; with just a little more attention, it could be even
better than VC6. I know we've all been asking for this to varying degrees
ever since VC.NET 2002, but two releases later, it's the same old thing.
Hopefully the renewed interest in native code will translate into these IDE
improvements everyone wants. Then again, if MFC is considered unimportant
for new development, I wouldn't expect too much.

--
Doug Harrison
Visual C++ MVP
 
 
Daniel





PostPosted: Sun May 20 06:12:38 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core?

> The C++ Standard requires that std::string::reference be an actual
> reference instead of a class type, and this forbids COW.

..but VC6's std::string is much older than the standard.

> >>In VS200x the implementation of std::string (and that of CString, too, BTW)
> >>uses a small-string optimization rather than shared buffers and COW,
> >>specifically to avoid such threading problems.
>
> CString remains COW (real COW, that is).

Really? OK, if that's the case my memory was playing up.

Cheers,
Daniel.




 
 
Joseph





PostPosted: Sun May 20 11:57:35 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? STL was an informal proposal for many years before being made rigorous enough to be
adopted by the C++ Standards Committee, so the COW idea may have been an optimization that
was within the scope of the informal proposal but forbidden by the formal adoption.
joe





>> The C++ Standard requires that std::string::reference be an actual
>> reference instead of a class type, and this forbids COW.
>
>..but VC6's std::string is much older than the standard.
>
>> >>In VS200x the implementation of std::string (and that of CString, too, BTW)
>> >>uses a small-string optimization rather than shared buffers and COW,
>> >>specifically to avoid such threading problems.
>>
>> CString remains COW (real COW, that is).
>
>Really? OK, if that's the case my memory was playing up.
>
>Cheers,
> Daniel.
>
>
>
Joseph M. Newcomer [MVP]

Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
 
 
Doug





PostPosted: Sun May 20 12:52:28 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? On Sun, 20 May 2007 12:12:38 +0100, Daniel James




>> The C++ Standard requires that std::string::reference be an actual
>> reference instead of a class type, and this forbids COW.
>
>..but VC6's std::string is much older than the standard.

The C++ Standard came out in 1998, and VC6 came out in 1998. Moreover,
Dinkumware certainly wrote the library according to the draft standard,
which was no different than the finalized standard in this respect. My
point was, VC6's std::string does not use real COW, nor does any
standard-compliant implementation; they can't, and I explained why in my
previous message.

--
Doug Harrison
Visual C++ MVP
 
 
Geeky





PostPosted: Mon May 21 09:07:14 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? You are preaching to the choir there, Joe. I was merely pointing out
that Microsoft in its default win32 configuration does not honor the
assigned ports in the range 1025 to 5000. On other machines vendors
reccomend reaching further into the assigned port range to free up
their assigned ports for customers.

The main point I wanted to make is that you cannot assume that ANY
port is available without examining the registry of a win-XP server
2000+ machine.

Yes, there is a standard, and no MIcrosoft does not honor it.

-Kurt


On Fri, 18 May 2007 23:47:57 -0400, Joseph M. Newcomer


>No, it is actually in the area of "unassigned ports". But it is really important, before
>choosing an apparent random number for a port, to at least look at the existing IANA
>assignments. For a product, you can apply (no charge!) for a port number. Note that I am
>registered for 5428, which is actually one of my clients.
>
>10000 and beyond are also in the Registred port area, and ports up to 0xBFFF have many
>assignments in the list. Therefore, it is largely inappropriate to use any ports in this
>range because of the potential for current or future conflicts with actual registered
>ports.
> joe
>

>
>>HI Joe,
>>
>>Nice article on threaded sockets!
>>
>>I just wanted to point out that Microsoft has a different view of TCP
>>port usage than the rest of the world does; and as a result your usage
>>of the TCP/IP port 0xC001 to accept connections could fail because
>>this is in the range of epehmeral ports which are dynamically assigned
>>by the OS for temporary connections.
>>
>>By default the ephemeral range is split from 1025 to 5000 (default for
>>MaxUserPort) and from 49152 to 65535. You can also reserve ports so
>>that they are excluded from ephemeral assignment.
>>
>>The reason the Microsoft guy picked the "random port" around 10000 was
>>because he knew it was NOT in the ephemeral range.
>>
>>See this technical article for more explanation:
>>http://www.microsoft.com/technet/community/columns/cableguy/cg1205.mspx
>>
>>Oracle, for example, reccomends changing MaxUserPort to 13000, then to
>>set ReservedPorts to 1024-8000 leaving 8001 to 13000 for ephemeral
>>use.
>>
>>XP-professional actually starts using ephemeral ports at 3000 to avoid
>>painful IANA usage collisions.
>>
>>Your choice of 0xC001 would probably never cause a problem because the
>>machine would have to plough though all of the ephemeral ports in the
>>low range first, but to be thorough, you should add 49153-49153 to the
>>ReservedPorts in the registry.
>>
>>On the other hand, the machine could be configured so that MaxUserPort
>>is set to 49152 in which case your port would be the first one to be
>>hit. It pays to examine the machine's configuration on setup and add
>>your service's port range to the reserved list in the registry.
>>
>>Thanks again for the great article,
>>-Kurt
>>
>>On Fri, 18 May 2007 01:05:54 -0400, Joseph M. Newcomer

>>
>>>That particular example is one of the most egregiously poor examples ever written, since
>>>it gets sockets wrong, threading wrong, and synchronization wrong. It is also not
>>>Unicode-aware or platform-independent, and it gets the fundamental interfaces to messaging
>>>wrong. It exhibits varioius aspects of extremely poor programming style, including an
>>>complete misunderstanding of the role of stdafx.h, the C++ language, abstraction,
>>>implementation, and fundamental good coding practice. Other than that, there's nothing
>>>wrong with it.
>>>
>>>See my rewrite of this horrendous article on
>>>
>>>http://www.flounder.com/kb192570.htm
>>>
>>>I would not trust that KB article code as far as I could heave a 1970s mainframe. Not to
>>>put too fine a point on it, it is almost entirely crap. My code compiles and runs,
>>>correctly, on Win32, Win64, in both ANSI and Unicode modes, and uses UTF-8 as its
>>>interchange format.
>>>
>>>There is nothing you can salvage in that code. I tried, and there are so few lines in
>>>common that it is clear that this code should be removed from the MSDN (I have already
>>>submitted this as a formal request: rewrite it, use my example, or get rid of it
>>>entirely--code this bad must not be allowed to persist)
>>> joe

>>>
>>>>


>>>>> Multicore support is irrelevant. VS6 supports it just fine. Multicore
>>>>> support, as you
>>>>> observed, is set in the BIOS. The compiler and runtime have nothing to do
>>>>> with this.
>>>>>
>>>>> I was writing multiprocessor apps in VS6 back when it was new, and they
>>>>> work just fine. No
>>>>> service packs are required to achieve this (although you should be using
>>>>> VS6 SP5 just for
>>>>> all the bug fixes you get)
>>>>>
>>>>> Multicore capability cannot be enabled or disabled from an application
>>>>> because it is a
>>>>> property of the BIOS/boot time configuration. Therefore, the compiler,
>>>>> runtime, etc. are
>>>>> completely irrelevant to the issue.
>>>>>
>>>>> I wrote multiprocessor apps in VS6 that ran just fine under NT4.
>>>>>
>>>>> How are you determining that your app "does not run" on multiple
>>>>> processors?
>>>>> joe
>>>>>


>>>>>
>>>>>>I am using VC++ 6.0. My most "thread intensive" app does not run with
>>>>>>multi-core enabled in the P-4 Intel motherboard systems we use. Always
>>>>>>need
>>>>>>to set BIOS to enable single core.
>>>>>>
>>>>>>What platform or service pack do I need to take advantage of multi-core
>>>>>>technology?
>>>>>>
>>>>>>Thanks
>>>>>>Tom Salicos
>>>>>>
>>>>> Joseph M. Newcomer [MVP]

>>>>> Web: http://www.flounder.com
>>>>
>>>>
>>>>
>>>>I made the ASSumption that I needed something different because disabling
>>>>multi-core stopped my problem. My bad. The offending app is based on the
>>>>demo program "AsyncClientServer" demo
>>>>http://support.microsoft.com/kb/192570 and seemingly runs without a hitch.
>>>>The client side and server side are split between two of our systems. The
>>>>client side runs on WinXP Pro and has the problem. If it runs at all, it is
>>>>sluggish. Usually it "crashes" immediately an the error is (paraphrased)
>>>>"Application requested termination in an abnormal fashion". Does that tell
>>>>me anything?
>>>>
>>>>Now that I know it's me, I'll start troubleshooting.
>>>>
>>>>Thanks
>>>>
>>>>Tom Salicos
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>>>>
>>>Joseph M. Newcomer [MVP]

>>>Web: http://www.flounder.com
>>>MVP Tips: http://www.flounder.com/mvp_tips.htm
>Joseph M. Newcomer [MVP]

>Web: http://www.flounder.com
>MVP Tips: http://www.flounder.com/mvp_tips.htm
 
 
Alexander





PostPosted: Mon May 21 10:40:17 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? There are well-known ports in that range. For example, iSCSI target and iSNS
server.




> You are preaching to the choir there, Joe. I was merely pointing out
> that Microsoft in its default win32 configuration does not honor the
> assigned ports in the range 1025 to 5000. On other machines vendors
> reccomend reaching further into the assigned port range to free up
> their assigned ports for customers.
>
> The main point I wanted to make is that you cannot assume that ANY
> port is available without examining the registry of a win-XP server
> 2000+ machine.
>
> Yes, there is a standard, and no MIcrosoft does not honor it.
>
> -Kurt
>
>


 
 
Geeky





PostPosted: Mon May 21 12:46:03 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? Yes Indeed Alexander,

You hit the nail on the head there!

Oracle deals with it as one of three options on this page:

http://download-east.oracle.com/docs/cd/B31017_01/winitan.1013/install/reqs.htm
How to Avoid Conflicts with Ephemeral Ports

And this is causing plenty of confusion and pain in general. Some
examples are:

http://lists.planet-lab.org/pipermail/users/2004-September/000653.html

http://www.webservertalk.com/message397678.html

http://www.hsc.fr/ressources/articles/win_net_srv/ephem_port_alloc.html

http://support.microsoft.com/kb/815295

Anyhow, I asked myself if perhaps I could use the approach reccomended
by the oracle link above to just coerce Windows XP to behave "the
right way". In an effort to do that I tried the following registry
modifications on my winXP pro. machine running on a domain.

===========================
Warning! try this at your own risk.
===========================

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"MaxUserPort"=dword:0000ffff
"ReservedPorts"=hex(7):31,00,30,00,32,00,35,00,2d,00,34,00,39,00,31,00,35,00,\
31,00,00,00,00,00

=================================

The above sets the maxuserport to the top (65535) and tells windows
not to use 1025 to 49151 for its ephemeral ports.

This forces XP to allocate ephemeral ports starting with 0xC000 which
I believe is closer to the standard. So far it has worked for me but
I fear it is an imperfect solution because it blocks wildcard binds,
and if a program just gave up at that point instead of going on to
bind each port individually (which would work) there could be trouble.

Too bad there's not just an "AdhereToIANA" flag in the registry.

-Kurt


On Mon, 21 May 2007 08:40:17 -0700, "Alexander Grigoriev"


>There are well-known ports in that range. For example, iSCSI target and iSNS
>server.
>
>


>> You are preaching to the choir there, Joe. I was merely pointing out
>> that Microsoft in its default win32 configuration does not honor the
>> assigned ports in the range 1025 to 5000. On other machines vendors
>> reccomend reaching further into the assigned port range to free up
>> their assigned ports for customers.
>>
>> The main point I wanted to make is that you cannot assume that ANY
>> port is available without examining the registry of a win-XP server
>> 2000+ machine.
>>
>> Yes, there is a standard, and no MIcrosoft does not honor it.
>>
>> -Kurt
>>
>>
>
 
 
Tom





PostPosted: Wed May 23 14:19:04 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? The example program mentioned (kb/192570) runs fine in Dual Core mode. About
two years ago I stripped the example down to bare bones, then built it back
up to fit my needs.

My program "crashes" immediately and the error is this:
"This application has requested the Runtime to terminate it in an unusual
way".

It's an MFC dialog-based application. Service Pk is 6

On a development system with Dual Core enabled, the error does *not* occur
in Debug.
Occasionally it does not occur in Release mode either. Also, started from
the DeskTop it may not always occur.

When the error occurs in Release Mode the call stack window shows the
following;

KERNEL32! 7c812a5b()
MSVCRT! 77c2272c()
MFC42! 73e309c1()
MFC42! 73ddbaf0()
MFC42! 73de9562()
MFC42! 73de5f14()
MFC42! 73de0bc7()
MSVCRT! 77c3a3b0()
KERNEL32! 7c80b683()

My program starts from zero to ten client threads to pull data from our
control systems.
The program does not crash if only one connection is enabled.

A loop starts the threads by calling my DoConnect(). I wound up putting a
Beep() in that loop as a troubleshooting tool. With the beep, no more
crash. I cut the Beep() down to 10ms and no more crash. Remove the Beep()
and it crashes.

If I start the app with all connections disabled then enable them one at at
time, there is no crash.

It seems like the delay from the Beep() a helpful delay but I don't know
why.

In my app CClientThread is derived from CWinThread and has the member
m_Socket which is derived from CAsyncSocket. DoConnect() starts a new
thread each time it's called.

I have proven that the crash occurs before the loop that calls DoConnect()
completes. It happens whether any connection is made or not. So no
OnConnect or OnReceive has ever occured and the app has not tried to use the
connection.

This is the gist of the code:
void StartAllThreads()
{
for(int i=0; i < nNumConnections; ++i)
{
DoConnect(Name of PC, etc );
}

AfxMessageBox("Hi ") // (debugging) The crash occurs before this point.
}


bool CAsyncClientDlg::DoConnect(
{
// Start the client thread suspended
CClientThread* pThread =
(CClientThread*)AfxBeginThread(RUNTIME_CLASS(CClientThread),
THREAD_PRIORITY_NORMAL, 0, CREATE_SUSPENDED);
if (pThread == NULL)
{
// error message
return FALSE;
}

// Set a few variables via pThread->
//

// Let thread run
pThread->ResumeThread();
return TRUE;
}

Again, problem does not occur if I put a delay between thread starts. But I
hate to do that without knowing what is actually causing the error.

Ideas ???

Thanks,
Tom


 
 
Joseph





PostPosted: Thu May 24 00:05:07 CDT 2007 Top

MFC >> Minimum VC++ for Multi-Core? You have some serious synchronization bug somewhere. The symptoms you describe are
characteristic of race conditions that will show up on multiprocessors, where threads can
start immediately, vs. uniprocessors, where there are delays in starting threads.

As I pointed out in my article, kb192570 is horrible in its structure; it gets threading
wrong, synchronization wrong, interthread communication wrong, and sockets wrong, so using
it as a basis is quite likely to result in complete catastrophe. I would be DEEPLY
suspect of ANY code based on that example that was anything other than a total rewrite
that threw away nearly all of the original code, all of the synchronization of the
original code, all of the interthread communication of the original code, and all of the
socket handling code of the original code. If it ever worked, it was akin to a miracle. I
don't think it ever worked correctly. It would not surprise me in the slightest that any
program based on it would crash immediately on a multiprocessor; what was amazing was that
nothing ever crashed on a uniprocessor.

In order to get something that was remotely production quality, I essentially had to
discard all of the code and rewrite it.

See my essay on this topic on my MVP Tips site.
joe


>The example program mentioned (kb/192570) runs fine in Dual Core mode. About
>two years ago I stripped the example down to bare bones, then built it back
>up to fit my needs.
>
>My program "crashes" immediately and the error is this:
>"This application has requested the Runtime to terminate it in an unusual
>way".
>
>It's an MFC dialog-based application. Service Pk is 6
>
>On a development system with Dual Core enabled, the error does *not* occur
>in Debug.
>Occasionally it does not occur in Release mode either. Also, started from
>the DeskTop it may not always occur.
>
>When the error occurs in Release Mode the call stack window shows the
>following;
>
>KERNEL32! 7c812a5b()
>MSVCRT! 77c2272c()
>MFC42! 73e309c1()
>MFC42! 73ddbaf0()
>MFC42! 73de9562()
>MFC42! 73de5f14()
>MFC42! 73de0bc7()
>MSVCRT! 77c3a3b0()
>KERNEL32! 7c80b683()
>
>My program starts from zero to ten client threads to pull data from our
>control systems.
>The program does not crash if only one connection is enabled.
>
>A loop starts the threads by calling my DoConnect(). I wound up putting a
>Beep() in that loop as a troubleshooting tool. With the beep, no more
>crash. I cut the Beep() down to 10ms and no more crash. Remove the Beep()
>and it crashes.
>
>If I start the app with all connections disabled then enable them one at at
>time, there is no crash.
>
>It seems like the delay from the Beep() a helpful delay but I don't know
>why.
>
>In my app CClientThread is derived from CWinThread and has the member
>m_Socket which is derived from CAsyncSocket. DoConnect() starts a new
>thread each time it's called.
>
> I have proven that the crash occurs before the loop that calls DoConnect()
>completes. It happens whether any connection is made or not. So no
>OnConnect or OnReceive has ever occured and the app has not tried to use the
>connection.
>
>This is the gist of the code:
> void StartAllThreads()
> {
> for(int i=0; i < nNumConnections; ++i)
> {
> DoConnect(Name of PC, etc );
> }
>
> AfxMessageBox("Hi ") // (debugging) The crash occurs before this point.
> }
>
>
> bool CAsyncClientDlg::DoConnect(
> {
> // Start the client thread suspended
> CClientThread* pThread =
>(CClientThread*)AfxBeginThread(RUNTIME_CLASS(CClientThread),
>THREAD_PRIORITY_NORMAL, 0, CREATE_SUSPENDED);
> if (pThread == NULL)
> {
> // error message
> return FALSE;
> }
>
> // Set a few variables via pThread->
> //
>
> // Let thread run
> pThread->ResumeThread();
> return TRUE;
> }
>
>Again, problem does not occur if I put a delay between thread starts. But I
>hate to do that without knowing what is actually causing the error.
>
>Ideas ???
>
>Thanks,
>Tom
>
Joseph M. Newcomer [MVP]

Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm