|
Answers:
1. it is necessary to declare the variables volatile on some systems
to prevent using cached values, you'll be fine by declaring all the
integer indexes unRead/unWrite etc... as volatile
2. the classes are thread safe for the single situation where you have a single
producer (writer) and a single consumer (reader) in different
threads. It is NOT safe for multiple consumers / multiple producers.
3. The two functions IncTheReadPtr(void) and IncTheWritePtr(void) are there
only if you want to skip some entries in the circular buffer in reading
or writing for some particular reason you know.
Hope that helps
Cheers
Federico
|
|
|
|
|
Two changes on the code to make an ATOM operation.And seems that the following declaration should be declared as volatile.
volatile unsigned int unRead; <br />
volatile unsigned int unWrite;
<br />
void CDoubleBuffer::Write(void* pBuf, unsigned int unBytesTo)<br />
{ <br />
unsigned int unTryWrite = (unWrite+1)%2;<br />
while( unRead == unTryWrite ) { ::Sleep(10); } <br />
::MoveMemory( pAlloc[unTryWrite], pBuf, __min(unBytesTo,unSize) ); <br />
unWrite = unTryWrite;<br />
}<br />
<br />
void CDoubleBuffer::Read(void* pBuf, unsigned int unBytesFrom)<br />
{ <br />
while( unRead == unWrite ) { ::Sleep(10); } <br />
unsigned int unTryRead = (unRead+1)%2; <br />
::MoveMemory(pBuf, pAlloc[unTryRead], __min(unBytesFrom,unSize)); <br />
unRead = unTryRead;<br />
}<br />
If any error, please make me know.Thanks. Good job.
The world is fine.
|
|
|
|
|
Note:
1. it is necessary to declare the variables volatile on some systems
to prevent using cached values, you'll be fine by declaring all the
integer indexes unRead/unWrite etc... as volatile
2. the classes are thread safe for the single situation where you have a single
producer (writer) and a single consumer (reader) in different
threads. It is NOT safe for multiple consumers / multiple producers.
3. The modifs you've done are good even if don't understand why
you changed the way you increment the pointers
it is not important to increment pointers in an atomic manner
as there will be only two threads: one writer and one reader.
If you want atomicity then you shall use InterlockedIncrement
/ Decrement functions. But it is a wasted effort here.
Hope that helps
Cheers
Federico
|
|
|
|
|
Hello Federico,
Thanks for your great help. It makes me clear on the problems I met recently.
Many many thanks for your kind help.
Sam/Br.
federico.strati wrote: Note:
1. it is necessary to declare the variables volatile on some systems
to prevent using cached values, you'll be fine by declaring all the
integer indexes unRead/unWrite etc... as volatile
2. the classes are thread safe for the single situation where you have a single
producer (writer) and a single consumer (reader) in different
threads. It is NOT safe for multiple consumers / multiple producers.
3. The modifs you've done are good even if don't understand why
you changed the way you increment the pointers
it is not important to increment pointers in an atomic manner
as there will be only two threads: one writer and one reader.
If you want atomicity then you shall use InterlockedIncrement
/ Decrement functions. But it is a wasted effort here.
Hope that helps
Cheers
Federico
|
|
|
|
|
here you find the revised version of double buffer,
there were errors in my code, sorry!
-----------
void CDoubleBuffer::Write(void* pBuf, unsigned int unBytesTo)
{
unsigned int unTryWrite = (unWrite+1)%2;
while( unRead == unTryWrite ) { ::Sleep(10); }
::CopyMemory( pAlloc[unWrite], pBuf, __min(unBytesTo,unSize) );
unWrite = unTryWrite;
}
void CDoubleBuffer::Read(void* pBuf, unsigned int unBytesFrom)
{
while( unRead == unWrite ) { ::Sleep(10); }
::CopyMemory(pBuf, pAlloc[unRead], __min(unBytesFrom,unSize));
unRead = (unRead+1)%2;
}
-----------
|
|
|
|
|
Well i looked a solution to call function from a process that is complitly different from another process so i readed about Interprocess Communication. Now i have only seen some data moving data copying and some text show up tutorials but there is nothing about how to call a function from another process can anyone point me somewhere...?
|
|
|
|
|
Check out Remote Procedure Call at MSDN . It's a tough topic, however.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
You could use any of the IPC mechanisms to send a 'notification' from one process to another. The other process should handle this notification and execute code appropriately.
See here for an example: http://www.flounder.com/messages.htm[^]
There are some really weird people on this planet - MIM.
|
|
|
|
|
In MFC it can be encrypted / decrypted a file ( any kind of file , ex. rar , mp3 , psd , avi ) ?
|
|
|
|
|
See Encrypting and Decrypting at MSDN .
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
What's the best way to find newline in char[] str and put text after this line?
|
|
|
|
|
what language? C? C++? MFC? what kind of string? isn't there some documentation on the language and strings you are using?
|
|
|
|
|
"Best" is a subjective term and only you can answer what is best for your situation. Have you looked at strchr() ?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
TCPMem wrote: What's the best way to find newline in char[]
Searching for.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
you mean Google? Bing? Baidu?
|
|
|
|
|
No, I meant, you know, for , if , ...
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
hello guys... what does these three lines of code mean...thnx
#if _MSC_VER > 1000
#pragma once
#endif
|
|
|
|
|
#pragma once is an include guard: the file will be included only once. This is similar has having the text in the file wrapped into a
#ifndef .....
#define
#endif
section.
I think this pragma was not available in the first versions of the compiler (_MSC_VER), that is why it is wrapped into the #if/#endif section.
|
|
|
|
|
and what is this??
_MSC_VER > 1000
|
|
|
|
|
If the compiler version is higher than version 10 (not sure, you have to google to see how the versions are encoded), then the pragma is used.
|
|
|
|
|
functionality gets added to windows all the time, and data structures sometimes get expanded. To cope with these, Microsoft has one overall version number in _MSC_VER, which they use to have their header files adapt to the situation.
Example: since Vista, the LVITEM struct has some new fields.
|
|
|
|
|
They hide it inside the documentation.
--Led Mike
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
CPallini wrote: They hide it inside the documentation.
Bastards!
|
|
|
|
|
who boss...... ayyo ayyo yo
|
|
|
|
|
BTW, it's been a very long time I didn't see him !
|
|
|
|