|
does named pipe count? if the function is writing to the named pipe and the function is called in parallel will that be a problem? or does named pipe handle that scenario automatically?
if not then i should only call the write function to the named pipe one at a time.
|
|
|
|
|
A named pipe certainly counts. I wouldn't think that named pipe access would be thread-safe. Proper thread safety depends on too many external factors. If you are using overlapped I/O, that changes things as well.
The conservative approach would be to protect your write function with a critical section.
|
|
|
|
|
You can call the DLL function in parallel, of course. But you have to be careful since your DLL function maybe not thread safe.
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.
[my articles]
|
|
|
|
|
hi thanks for the answer....
now my problem is if i dont use a lock within the function... and the function is as shown below
void function(myobj* obj)
{
myobj *objTemp = new myobj;
objTemp->a = obj->a; // or if i use memcpy here
send to namepipe...
}
will there be a problem if the function is called in parallel?
thanks again.
|
|
|
|
|
You have to worry about shared resources, inside your function, as far shared resources are not used you're safe. You should try to figure out what happens if the thread executing the function loses the CPU possibly in favour of another thread running the same function: if such action is harmless, then you're safe (for instance if the named pipe is shared then a meaningless message can result if the threads write in parallel to)
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.
[my articles]
|
|
|
|
|
then my question next question will be if the named pipe is used only by that function.. however if that function is called in parallel causing 2 or more writing in the named pipe will that be a problem? or is it automatically handled by the named pipe that if there is currently a write in progress then other write functions will not interfere until it is finished?
|
|
|
|
|
CPalline wrote: or instance if the named pipe is shared then a meaningless message can result if the threads write in parallel to
CPallini already answered that question for you. If you can write to the named pipe at the same time from multiple threads, then it doesn't matter if it would be the same function or different functions - It's still BAD.
After all, the talking-to-the-named-pipe won't happen in MyFunctionA, or MyFunctionB - it will happen in ::WriteFile, which both of your functions can call.
Iain.
Iain Clarke appearing by Special Request of CPallini.
|
|
|
|
|
Hello everyone,
I am studying the manual for DLLMain, it is mentioned,
http://msdn2.microsoft.com/en-us/library/ms682583.aspx
--------------------
If your DLL is linked with the C run-time library (CRT), the entry point provided by the CRT calls the constructors and destructors for global and static C++ objects. Therefore, these restrictions for DllMain also apply to constructors and destructors and any code that is called from them.
--------------------
My questions are,
1. How could I know if a project whether DLL or EXE or static lib is linked with C Runtime library?
2. Why we need C Runtime library in a C++ project? We need to call some legacy C functions like printf other than pure C++ functions std::cout?
3. If we use default entry point in DLL (DllMain), does it mean C Runtime Library is dynamically linked?
thanks in advance,
George
|
|
|
|
|
George_George wrote: 1. How could I know if a project whether DLL or EXE or static lib is linked with C Runtime library?
It depends on the version of Visual Studio you are using. In general, right-click on the project, select Properties, and then look through the compiler and linker options. In all likelihood you are linking with the C runtime library.
George_George wrote: 2. Why we need C Runtime library in a C++ project? We need to call some legacy C functions like printf other than pure C++ functions std::cout?
The C/C++ libraries are pretty intertwined. "std::cout" isn't a 'pure C++ function' which is provided by the compiler; it's a function in the C++ library. The C++ library has the same DllMain restraints.
George_George wrote: 3. If we use default entry point in DLL (DllMain), does it mean C Runtime Library is dynamically linked?
No. The two don't have anything to do with each other. The C runtime library is dynamically linked when you link with the import library for it's DLL. It is statically linked when you link with the object library directly. Which you do is selected by compiler and linker options.
|
|
|
|
|
Thanks Gary!
Great reply! Two more comments,
1.
Gary R. Wheeler wrote: It depends on the version of Visual Studio you are using. In general, right-click on the project, select Properties, and then look through the compiler and linker options. In all likelihood you are linking with the C runtime library.
Which IDE are you using? I am using Visual Studio 2008, and it is appreciated if you could show me your option in your IDE. If you are using other version of Visual Studio, I think it should be similar. I have checked compiler and linker option one by one, but can not find the result.
2.
Gary R. Wheeler wrote: The C++ library has the same DllMain restraints.
What do you mean "DllMain restraints"?
regards,
George
|
|
|
|
|
"restraints" = "restrictions". Look at the quote you made in your initial post.
Iain.
Iain Clarke appearing by Special Request of CPallini.
|
|
|
|
|
|
If the documentation says so, I'd do no better than to look at it too.
I think one of the combinations has to do with being thread safe too, but again, msdn will be more authorative than me.
Iain
Iain Clarke appearing by Special Request of CPallini.
|
|
|
|
|
Thanks Iain,
I just want to confirm with you since MSDN document is not describing always explicitly.
regards,
George
|
|
|
|
|
Iain Clarke wrote: one of the combinations has to do with being thread safe
All of the run-time libraries are thread-safe now. I believe they dropped the non-thread-safe versions after VC6.
|
|
|
|
|
Well, some of us are Luddites, and still use VC6.
If it wasn't for Windows Mobile programming, I'd still be using 6 for all my work, instead of most.
But I'm glad to know they've finally made their library re-entrant. I was quite schocked to find it wasn't...
Iain.
Iain Clarke appearing by Special Request of CPallini.
|
|
|
|
|
Hi all
I want to copy some file(like .dll ,.exe etc) from some perticular location and paste to another location and i m using Shellexecute but it is not working. so can u help me out get it done.
shellexecut(m_hwd, "copy", "Path of the source directory","path of the destination directory",NULL,NULL);
Thanks in advance
RYK
|
|
|
|
|
|
Here is the code:
<br />
#define PP_CAT(a,b) PP_CAT_(a,b)<br />
#define PP_CAT_(a,b) a##b<br />
<br />
#define PP_STR(s) PP_STR_(s)<br />
#define PP_STR_(s) #s<br />
<br />
<br />
class CNamedTreePropertyBase<br />
{<br />
public:<br />
CNamedTreePropertyBase() : name(0), pParent_(0) {}<br />
CNamedTreePropertyBase(const TCHAR * const Name, <br />
CNamedTreePropertyBase *pParent) : name(Name)<br />
, pParent_(pParent) {}<br />
<br />
const TCHAR *const name;<br />
virtual const TCHAR const *GetName() const = 0;<br />
CNamedTreePropertyBase *pParent_;<br />
};<br />
<br />
<br />
#define NAMED_PROP(Type, Var, InitialVal, pParentProp) \<br />
class PP_CAT(tag, Var) : public CNamedTreePropertyBase \<br />
{ \<br />
public: \<br />
const TCHAR * const name; \<br />
Type value; \<br />
PP_CAT(tag, Var) () : name(PP_STR(Var)) \<br />
, value(InitialVal) \<br />
, CNamedTreePropertyBase(name, pParentProp) {} \<br />
const TCHAR const *GetName() const {return name;} \<br />
} Var; \<br />
<br />
<br />
struct A<br />
{<br />
NAMED_PROP(std::string, prop, _T("some value"), 0);<br />
NAMED_PROP(std::string, child_prop, _T("some value"), reinterpret_cast<CNamedTreePropertyBase*>(&prop));<br />
};<br />
The MSVC 6.0 compilier, and it issues an error:
E:\Projects\Sources\TestVarName_1.0_question\TestVarName.cpp(56) : error C2440: 'reinterpret_cast' : cannot convert from 'class A::tagprop A::*' to 'class CNamedTreePropertyBase *'
There is no context in which this conversion is possible
How can it be possible to convert the pointer correctly?
|
|
|
|
|
|
Hello everyone,
There are two scale parameter in perfmon tool and I am not sure how to calculate the real value of working set bytes from the two scale parameters. Could anyone help please?
The two scale parameters are,
1. At the bottom of perfmon main screen, there is a scale column
2. Properties dialog --> Graph Tab --> Vertical Scale
If I set Vertical Scale max to 1,000,000 and the scale column for working set is 0.0000100, and the current value of displayed working set is 4000, what is the real bytes of working set?
thanks in advance,
George
|
|
|
|
|
I have a question :
Why do you need to calculate the real values of the working sets?
|
|
|
|
|
I need to get the real (actual) value of physical memory consumed. Any idea about my original question, Maximilien?
regards,
George
|
|
|
|
|
two project A and B connect by socket
A:
<br />
int iSend = send(sock,buf,1024*16,0); <br />
B:
<br />
fd_set fdread, fdExcept;<br />
FD_ZERO(&fdread);<br />
FD_ZERO(&fdExcept); <br />
FD_SET(ssock,&fdread); <br />
FD_SET(ssock,&fdExcept); <br />
<br />
int iRet = select(0, &fdread, NULL, &fdExcept, &timeOut);<br />
<br />
<br />
if(iRet < 1) <br />
{ <br />
break;<br />
} <br />
else<br />
if(FD_ISSET(ssock,&fdExcept)) <br />
{ <br />
<br />
break;<br />
} <br />
else<br />
if(FD_ISSET(ssock,&fdread)) <br />
{<br />
<br />
<br />
<br />
char buf[1024*16] = {0};<br />
<br />
iRecv = recv(ssock, buf, 1024*16, 0);<br />
}<br />
<br />
if B not use select, but only use
<br />
iRecv = recv(ssock, buf, 1024*16, 0);<br />
and that iRecv equals 1024*16
|
|
|
|
|
For stream-oriented protocols...
A recv() call is successful if the return value is anything
except 0 or SOCKET_ERROR. It's up to you to keep track of
how many bytes are received each call and call recv()
additional times if necessary until the amount of data you
are expecting is received.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
