DLL Function call
-
This depends on the
myobjclass, and the type of member 'a'. If 'a' is a simple type (anintfor 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. Supposeais a linked list of items allocated from a global pool. The assignment operator that performs theobjTemp->a = obj->aoperation would probably need to allocate items from the global pool. That might make this operation and this function not thread-safe.Software Zen:
delete this;
Fold With Us![^] -
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 :)
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] -
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.
Software Zen:
delete this;
Fold With Us![^] -
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.
Software Zen:
delete this;
Fold With Us![^]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? :)
-
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. :)
-
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.
Software Zen:
delete this;
Fold With Us![^] -
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] -
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? :)
-
A 'global resource' is an object in the program that will be accessed by more than one thread.
Software Zen:
delete this;
Fold With Us![^]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. :)
-
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.
-
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.
Software Zen:
delete this;
Fold With Us![^]
