|
I explained this to the OP in another post.
While you're correct about locking (probably) not needed on a simple increment,
InterlockedIncrement does more:
SomeCriticalSection.Lock();
iy = (++iv);
returnval = iv;
SomeCriticalSection.Unlock();
return returnval;
Aother thread incrementing iv after the first thread increments it but before the first thread
has copied it could have an undesired effect 
Especially on reference counters, which is (probably) most often the reason InterlockedIncrement
and InterlockedDecrement are used.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
The variable is locked DURING the call, not after the call completes.
See here[^].
As Matthew mentioned, what's going on in the call is something like:
LONG InterlockedIncrement(LONG volatile* lpAddend)
{
SomeCriticalSection.Lock();
++(*lpAddend);
LONG returnval = *lpAddend;
SomeCriticalSection.Unlock();
return returnval;
}
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Hi All,
I know this has come up in the context of non-English speaking contributors in an effort to improve article quality. I'm all for it. I submit that the non-English speaking author has a better command of English than I have of his native tongue. So I am humbled by my own ignorance...
However, Subject Matter is a different story. I have a good understanding in some arenas. This knowledge extends sufficiently so that I feel I can provide feedbck and advice. One such area is Cryptography.
I am appaled at some of the articles submitted on Cryptography. In the following, I am not singling out the authors. I am trying to make a succint point.
The latest is TrueCrypt Explorer[^]. This library is using source code and presumably home grown ciphers from the notorius Tom St. Dennis of sci.crypt. Single handedly, he nearly ruined the usenet group with his arrogance and ignorance.
I assume the author is not versed on Cryptography, and as such has fallen victim to TSD's 'Proof by Intimidation' of his cryptosystem. I am not aware of a Cryptanalytic effort by any reputable cryptographer on his work.
Build your own cryptographically safe server/client protocol[^] is misleading because the author states something to the nature he is collecting 'true randomness', which is generally not possible in software.
CTrueRandom - Getting True Random Numbers[^] claims it generates 'True Random Numbers'. I assume the author meant nondeterminsitic method, similar to the noise resisitor placed on the hardware based PRNG board of a RS6000.
As a final example, I point you toward The Art & Science of Storing Passwords[^], where the article claims the practice of storing a password for recover on disk unencrypted is OK.
Jeff
|
|
|
|
|
This is an interesting idea, and I too have felt really aggravated by some of the poor articles posted here. I'm sure you know that historically, the CP editors take care of compliance with formatting, etc., but rarely get involved with content, unless there is a serious concern about plagiarism or something similar. I think that over time, the better articles are recognized and get better ratings.
But SMEs are a whole new thing. I can see how putting content responsibility in the hands of a few anointed SMEs could lead to personality problems just like the one you described. A heavy-handed SME could cause huge damage to the site's collaborative spirit (I'm thinking of another Usenet newsgroup, which is dominated by an obnoxious person who was beaten off when he tried the same stuff here). I think I would rather risk a few bad articles than having to contend with a situation like that.
Why don't you think that submitting (positive) comments on the article forums is the way to go?
|
|
|
|
|
Could the voting system be tweeked so that an article can be voted into oblivion by, for example, 'nill point' votes from 3 separate experts/moderators/SME? This might stop or at least slow down one bad egg from causing trouble but would allow a way to can really bad articles.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Hans
Apologies, I intended to vote your comment 5, but somehow managed to click 1 by mistake  - do you know any way to retract a vote?
I didn't particularly want to participate in this debate, but I agree that the submission of positive comments is a good strategy.
Best Regards
Cliff
|
|
|
|
|
Cliff Hatch wrote: do you know any way to retract a vote?
I think you have to send an email to sean@codeproject.com.
Thanks for telling me - now I won't think that Jeff is being mean. 
|
|
|
|
|
Cliff Hatch wrote: Apologies, I intended to vote your comment 5, but somehow managed to click 1 by mistake - do you know any way to retract a vote?
Perhaps Chris can help. I would post a questiion on the suggestion board (where this suggestion should have gone - I don't know how I managed to insert it into C++).
Jeff
|
|
|
|
|
Hi Hans,
Hans Dietrich wrote: I can see how putting content responsibility in the hands of a few anointed SMEs could lead to personality problems just like the one you described. A heavy-handed SME could cause huge damage to the site's collaborative spirit (I'm thinking of another Usenet newsgroup, which is dominated by an obnoxious person who was beaten off when he tried the same stuff here). I think I would rather risk a few bad articles than having to contend with a situation like that.
As Gary raised the same issue below, I was not not trying to create censorship.
I was thinking more the way a Book Proofer work: Make suggestions and comment on tecnical correctness. The author can choose to incorporate.
Jeff
|
|
|
|
|
The CodeProject is an informal, open, collaborative site. The approach you describe would convert it to a formal, closed, scholastic one. Demi-gods would 'vet' articles based on their own notion of accuracy, usefulness, and appropriateness.
I think the current approach with the article voting system and each article having its own forum is sufficient.
If you think these articles are poor articles, vote them down. Post a message in their forum stating THIS ARTICLE IS CRAP and explain why. Write a response article.
Software Zen: delete this;
|
|
|
|
|
Hi Gary,
Gary R. Wheeler wrote: The CodeProject is an informal, open, collaborative site. The approach you describe would convert it to a formal, closed, scholastic one. Demi-gods would 'vet' articles based on their own notion of accuracy, usefulness, and appropriateness.
The situation you describe (censorship) is worst than the current. I was not imagining an involuntary system.
Perhaps middle ground is the solution: the Content Editor makes suggestions. If the author chooses, he or she can incorporate the suggestions.
Gary R. Wheeler wrote: If you think these articles are poor articles, vote them down. Post a message in their forum stating THIS ARTICLE IS CRAP and explain why.
I try not to do this (I think it is very unprofessional). Again, I'd rather correct the problem at the source...
Gary R. Wheeler wrote: Write a response article.
In my case, I did: A Survey of Pseudo Random Number Generators[^]. Also, I did try to solicit feedback from two PhD's. Neither would comment. In either case, I tried by going to someone who knows more then me.
Humorously, the beginner article has only garnered a 4/5 rating
Jeff
|
|
|
|
|
I want to get buffers of all streams of a file. I searched msdn then i found ready functions
FindFirstStream and FindNextStream which i ve found in Windows Platform SDK.
These functions give me name of streams. So how can get data in these streams using their name ?
I guess i will use CreateFile and ReadFile again but , what must the parameter given to CreateFile , must it be only stream name or "filenametreamname" ??
Thank you very much...
|
|
|
|
|
Akin Ocal wrote: These functions give me name of streams. So how can get data in these streams using their name ?
You can append a colon and the stream name to the pathname of the file.
filenamename.ext:streamname
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Hello in my code i have this
double idf[50];
for (int zz = 0 ; zz < m_QueryWords ; zz++ )
{
idf[zz] = log10 ( (double)(nDoc/df[zz]) );
-> }
While i debug i have :
<code>name Value
df[zz] 2
idf[zz] 0.00000 (red colour just took the value)
nDoc 3
+this etc :P
zz 0 </code>
what i do wrong ?
I changed the code with
int location = f + (m_QueryWords*ii);
SCs = SCs + nArray.GetAt(location)*idf[f]*idf[f] ;
and now works
-- modified at 14:32 Saturday 2nd June, 2007
|
|
|
|
|
Immunity18 wrote: idf[zz] = log10 ( (double)(nDoc/df[zz]) );
Change to log10 ( (nDoc/(double)df[zz]) );
df[zz] needs to be a double in order to provide a floating point result.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
I posted a question before and got hint of "managed/unmanaged code".
I do heard "Managed C++", I guess it is another language - at least it is different from c++ hear.
my question is:
how to generate "managed code" in our C++, such as in MFC or Win32?
any samples if it is possible?
thx
|
|
|
|
|
Hope this article will help you.
Managed Code[^]
Regards,
Satips. ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
|
|
|
|
|
...or this article
Managed Extensions for C++ Programming[^]
It's not another language. It's an extension to Microsoft's C++ which allows you to use the
Common Language Runtime and the .NET framework.
Managed code is not compiled to processor machine code like regular C++ is. It is compiled to
an intermediate language that can run on an implementation of the Common Language Infrastructure
(CLI). At runtime, the intermediate language code is compiled to CPU-specific machine code and
executed. On a Windows machine with the .NET framework installed, this is done by the Common
Language Runtime (CLR), which is Microsoft's implementation of CLI.
In order for this to be possible from C++, it was necessary to extend the language to be able to
work with the common data types of the CLI specification and to work with the managed, garbage-
collected heap of the .NET framework.
The biggest impact IMO with managed C++ programming is with managed pointers. Objects allocated
on the managed heap can be moved at any time by the runtime. Objects allocated with malloc/new
don't move - that's what we're used to as C++ programmers. Also, managed objects are
automatically destroyed by the runtime.This means there's rules to follow when mixing managed and
unmanaged C++ code (mixed-mode programming).
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
//global
long i_Lock=0;
//use it in thread
int MyTread(void*p)
{
InterlockedIncrement(&i_Lock);
}
--------------------------
I am really confused, what is difference with
int MyTread(void*p)
{
i_Lock++;
}
???
it sounds nothing related to sinycronization, could u explain?
thx
|
|
|
|
|
The InterlockedIncrement() version is thread safe, the i_Lock++ version is not.
InterlockedIncrement() prevents any other thread from using i_Lock while it's being incremented.
InterlockedIncrement() also checks the result and gives a return value based on the result.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
includeh10 wrote: it sounds nothing related to sinycronization, could u explain?
sure it is !
you MUST lock a resource that can be modified by several threads at the same time, so that no data loss is possible.
imagine you do i_Lock++ as you suggest, but at the same time, another thread does i_Lock--, one of the 2 operations will be done for nothing...
at
|
|
|
|
|
my test code is as following:
the thread has been created for 5 times by CreateThread(), so I have 5 threads:
//---------- code
long i_Lock=0;
long i_Thread=0;
int WINAPI ZDlg::Thread_Simple(void*pv)
{
if(i_Thread==0)
{
::InterlockedIncrement(&i_Lock);
}
else
{
i_Lock++;
}
i_Thread++;
int iNum=0;
while(iNum<5)
{
iNum++;
Sleep(1000);
}
return 0;
}
//--------------------
so only first thread calls InterlockedIncrement(&i_Lock);
and other 4 call i_Lock++;
if i_Lock is really locked, its value must be 1.
but when I test the value in while() loops, it is 5.
so i_Lock++ works and i_Lock is not locked!
is something wrong?
|
|
|
|
|
How can it lock if you don't use InterlockedIncrement() for all cases? It can't.
The system has no way of knowing if you are changing the variable directly.
You have to use InterlockedIncrement() every place you increment the variable for it to work.
The way you've coded your thread, all 5 threads are going to increment the value regardless.
InterlockedIncrement() ensures the increment won't happen at the same time but it's still
going to happen as soon as another thread is done incrementing it.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
1) do you mean : if first thread calls InterlockedIncrement(&i_Lock) first, then second thread calls i_Lock++;
the i_Lock++ still works?
2) what does "same time" mean?
do u mean: if InterlockedIncrement(&i_Lock); are called at "same time" by two threads, only one call works?
but, a PC has only one CPU, it can not change a value at "same time" by 2 threads in any way (++ or InterlockedIncrement).
|
|
|
|
|
includeh10 wrote: 1) do you mean : if first thread calls InterlockedIncrement(&i_Lock) first, then second thread calls i_Lock++;
the i_Lock++ still works?
Yes. All the threads incrementinging i_Lock should use InterlockedIncrement() to do so. That's
the only way the operation will be thread safe.
includeh10 wrote: 2) what does "same time" mean?
do u mean: if InterlockedIncrement(&i_Lock); are called at "same time" by two threads, only one call works?
but, a PC has only one CPU, it can not change a value at "same time" by 2 threads in any way (++ or InterlockedIncrement).
While it's true it won't occur at the "same time" on a single-processor machine, it's best to
assume that logically it can. You have no control over when the system is going to switch threads.
If the switch occurs right in the middle of a thread changing the variable and another thread
takes over and changes that variable then the first thread resumes but the variable has changed.
That can be bad.
In the simple case of incrementing a long, chances are pretty good these days that it will take
a single machine-code instruction to do the increment. Theoretically one wouldn't need
to use thread synchronization because the active thread isn't going to change in the middle
of a CPU instruction.
InterlockedIncrement() does more than just increment though. It also checks the result and
returns the result. Now imagine doing all those operations without thread synchronization:
1) i_Lock = 0
2) Thread A increments i_Lock - i_Lock now == 1
3) Thread B becomes the executing thread
4) Thread B increments i_Lock - i_Lock now == 2
5) Thread B gets the value of i_Lock (2)
6) Thread A becomes the executing thread
7) Thread A gets the value of i_Lock (2)
i_Lock should have been 1 in thread A but thread B changed it before thread A was finished.
Now do the same with proper synchronization:
1) i_Lock = 0
2) Thread A calls InterlockedIncrement() to increment i_Lock
3) Thread B becomes the executing thread
4) Thread B calls InterlockedIncrement() to increment i_Lock
5) Thread B is put into a waiting state (paused) until Thread A's call to InterlockedIncrement()
is completed
6) Thread A becomes the executing thread
7) Thread A's call to InterlockedIncrement() completes, returning 1 (i_Lock == 1)
8) Thread B becomes the executing thread
9) Thread B's call to InterlockedIncrement() is allowed to continue
10) Thread B's call to InterlockedIncrement() completes, returning 2 (i_Lock == 2)
That's the expected behavior - first-come, first-serve Make sense?
InterlockedIncrement() and InterlockedDeccrement() are often used for object reference count
variables. When an object's reference count is 0, often the object should be destroyed.
Imagine not synchronizing this process (as described above). Two threads try to decrement the
ref count on an object, but both think the ref count is 0 after they have done so. Both threads
try to destroy the object - one succeeds, one crashes.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
