|
I would agree with Mr. Salsbery.
IStream* pStream=NULL;
then use
CreateStreamOnHGlobal(NULL,TRUE,&pStream);
then use the streams "Write" method to get the data from the buffer in,
pStream->Write(pBuf,nSize,NULL);
then use Image::FromStream or the constructor as you had been doing.
|
|
|
|
|
Don't forget to initialize COM for this technique.
|
|
|
|
|
Hi everyone!
Would like to ask...
if i have a DLL that implements a function.. this DLL is used by an EXE. can the call to the DLL function by the EXE be done in parallel? say the EXE implements several thread and each of these threads calls the DLL function. or is the call just 1 at a time?
Thanks for any help.
not so newbie 
|
|
|
|
|
The short answer is yes. Any number of threads can call a function in a DLL at the same time; the DLL calling mechanism allows this.
The real answer is it depends on the function in the DLL. The DLL function must be designed to be thread-safe. In other words, you must know that the function can be called from multiple threads safely. If the function uses a global resource, it must protect accesses to that resource so that its state isn't changed incorrectly by multiple threads.
If you don't know that the function is thread-safe, you can make it so by writing your own wrapper, something like this:
static CCriticalSection MyFunction_CS;
void Function(...);
void MyFunction(...)
{
MyFunction_CS.Lock();
Function(...);
MyFunction_CS.Unlock();
}Intead of calling Function(...) directly, you call MyFunction(...) which uses a critical section to ensure only a single thread at a time can call Function(...).
|
|
|
|
|
Hi! thanks so much for the answer.
if the function does not use global resoure and is something like below
void Function(myobj *obj){
myobj* objTemp = new myobj;
objTemp->a = obj->a;
};
will there be a problem if the function is called by multiple threads?
thanks again!
not so newbie
|
|
|
|
|
This depends on the myobj class, and the type of member 'a'. If 'a' is a simple type (an int for example) then this code is probably thread-safe as it is. If it is something more complicated that has its own assignment operator, then this function might not be safe.
Suppose a is a linked list of items allocated from a global pool. The assignment operator that performs the objTemp->a = obj->a operation would probably need to allocate items from the global pool. That might make this operation and this function not thread-safe.
|
|
|
|
|
sorry but what do you mean by global pool?
thanks.
not so newbie
|
|
|
|
|
A common approach to keeping the size of a data structure limited is to allocate a fixed number of items and place them in a list of their own at the beginning of the program. This list is called the 'pool'. When the program needs a new item, it removes one from the pool. When it's done with the item, it puts it back in the pool. If the pool is ever empty when it needs a new item, it knows that the data structure has reached its size limit and it can react accordingly.
This pool is a global resource. If you were to have multiple threads accessing it, thread 1 could be partway through removing an entry from the pool while thread 2 could attempt to add an entry to the pool. Pointers to the beginning and end of the pool could be set incorrectly. Later accesses might try to get an item from the pool that is really in use elsewhere, or items might be lost instead of being returned to the pool.
|
|
|
|
|
im not sure if i understand what you meant by a the global resource...
however the struct myobj as shown before is created everytime the function is called and sent as a data to a named pipe then the function returns.
will there be a problem in that case?
|
|
|
|
|
A 'global resource' is an object in the program that will be accessed by more than one thread.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
