|
Hi there.
I have an application ofwhich threads concurrently act on multiple instances of a certain class called CChannel.
CChannel has a method called ::Send which must be protected. For that end I put in a place a Critical section as a data member of CChannel then I call EnterCriticalSection and LeaveCriticalSecion within ::Send. I avoided to use a global critical
section for performance reasons : indeed I do'nt want to have a blocking scenario when thwo threads call ::Send on two different instances.
At some point of time, I need to delete a Channel object. Since threads hold references to the pointer addresses, the application can easily crash if one thread tries to use a certain address pointing to an object that has been deleted by another thread.
To overcome this, instead of communicating addresses, rather I communicate access numbers. these number serv as a key for a map that stores context structures containing the actual addresses and also the per-instance CriticalSection. So the CriticalSection which used to be a data member of Channel is now out of the class (I will be able to delete a Channel object, but still use its acorresponding CriticalSection)
Here my solution, I am not confident, I think it works, but anyway I will be happy to be helped with a much more solid solution.
<pre>//This is the wrapper structure. it contains the criticalsection, the pointer to CChanel
typedef struct ChannelContext
{
CChannel* pChannel;
CCriticalSection cs;
} ChannelContext;
typedef std::map<UINT,ChannelContext*> channelMapT;
channelMapT channelMap;
CCriticalSection csMap; //(used to protect the map).
//The following two function can be called without problem by any thread :
//This function is called by a thread when it needs to act on a certain CChannel.
//it is meant to provide safe access to the CChanell. the calling thread only needs to check if the retunred
//address is not null, then consume pContext->pChannel, then when it finishes its job with the Channel is calls
//pContext->LeaveCriticalSection(&pContext->cs).
ChannelContext* requireChannelByKey(UINT accessKey)
{
EnterCriticalSection(&csMap);
channelMapT::iterator myIt=channelMap.find(accessKey);
if(myIt!=channelMap.end())
{
ChannelContext* pContext=myIt->second;
EnterCriticalSection(&pContext->cs);
LeaveCriticalSection(&csMap);
return pContext;
}
LeaveCriticalSection(&csMap);
return NULL;
}
//Function to delete an object.
void deleteChannel(UINT accessKey)
{
EnterCriticalSection(&csMap);
channelMapT::iterator myIt=channelMap.find(accessKey);
if(myIt!=channelMap.end())
{
ChannelContext* pContext=myIt->second;
EnterCriticalSection(&pContext->cs);
//Delete the entry.
channelMap.erase(myIt);
delete pContext->pChannel;
LeaveCriticalSection(&pContext->cs);
delete pContext;
}
LeaveCriticalSection(&csMap);
}</pre>
Thank you in advance. Note, if someone have ideas how Windows manages its internal structure then please enlignten me.
I think that HANDLE just act like the accessKey : it hides the pointer addresss. But what about synchrnoization ?
Easy Profiler : a compile-time profiler for C++
www.potatosoftware.com
modified on Tuesday, April 7, 2009 4:07 AM
|
|
|
|
|
Ahmed Charfeddine wrote: typedef struct ChannelContext
{
CChannel* pChannel;
CCriticalSection cs;
} ChannelContext;
the CCriticalSection should be a pointer right?
What about using shared pointers? Check boost::shared_ptr[^]
-Sarath.
"Great hopes make everything great possible" - Benjamin Franklin
|
|
|
|
|
Thank you for your reply,
According to your suggestion, threads will act on the shared pointers instead of the pointers to the actual objects in memory.
Does that help avoid the program to crash when I explicitly delete an object and that another thread that tries to use it afterward ?
And what about synchronization ? If a thread is trying to use a share pointer, am I garanteed that the other thread that tries to access the same share pointer is blocked ?
Sarath. wrote: the CCriticalSection should be a pointer right?
In my case no.
I have anothe global function that creates a CChanel object. all it has to do is to create a new CChannelContext structure, initialize the CriticalSection and set the pChannel member to the address of the newly created CChannel then add the whol thing to the map. So in my point of view, creating the CriticalSection with the new operator or on the heap, is the same.
Easy Profiler : a compile-time profiler for C++
www.potatosoftware.com
|
|
|
|
|
Hello,
When I maximize MainFrame and then the child frame, the child frame window has the colors from the Mainframe window. It is as if the background of mainframe is seen in the child window.
What must the problem ?
Priya
|
|
|
|
|
Call the UpdateWindow method on the child window after maximizing.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
Hello,
My Application was not having this problem on my PC but when I transferred the application it started raising this problem. Is there any problem with operating systems
Priya
|
|
|
|
|
Hello,
When I maximize a mainframe window do I have to redraw the background color of the window or set it to a particular color.Because my application behaves differently for different PC where the operating system is the same.
Priya
|
|
|
|
|
How to show selected rows in ListCtrl. I tried with following code. But it is not working.
LVITEM LvItem;
memset(&LvItem,0,sizeof(LvItem));
LvItem.mask=LVIF_TEXT;
LvItem.cchTextMax = 256;
LvItem.iItem=0;
LvItem.iSubItem=0;
LvItem.pszText="1";
::SendMessage(hwnd,LVM_INSERTITEM,0,(LONG)&LvItem);
LvItem.pszText="2";
::SendMessage(hwnd,LVM_INSERTITEM,1,(LONG)&LvItem);
LvItem.pszText="3";
::SendMessage(hwnd,LVM_INSERTITEM,3,(LONG)&LvItem);
int nCount = m_ctrlList.GetItemCount();
int nRet = m_ctrlList.SetSelectionMark(1);
|
|
|
|
|
You could try m_ctrlList.SetItemState(1, LVIS_SELECTED, LVIS_SELECTED); if that is what you are asking.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
m_ctrlList.SetItemState(1, LVIS_SELECTED, LVIS_SELECTED) function is not working
|
|
|
|
|
Have you been able to insert items into the list control?
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
Yes. I can able to add items in listctrl.
|
|
|
|
|
I enabled "Show Selection Always" property in resource editor.It is working.Thanks
|
|
|
|
|
Roay wrote: ...is not working
Which is anything but helpful. Did it produce a compiler/linker error? Did it throw an exception? Did it fire an assertion? What did it return?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"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
|
|
|
|
|
LVS_EX_FULLROWSELECT, I mean, use it with SetExtendedStyle().
|
|
|
|
|
m_ctrlList.SetExtendedStyle(LVS_EX_FULLROWSELECT) is not working
|
|
|
|
|
Try like:
DWORD dwStyle = m_ctrlList.GetExtendedStyle();
dwStyle |= LVS_EX_FULLROWSELECT;
m_ctrlList.SetExtendedStyle(dwStyle);
|
|
|
|
|
it should set focuse on this ListCtrl,may be focuse problem.
you can try!! 
|
|
|
|
|
and then SetItemState(...).
if the focuse isn't on this control, it will not show the selected item.
|
|
|
|
|
if (CView::OnCreate(lpCreateStruct) == -1)
return -1;
Thanks
sft
modified on Monday, April 6, 2009 1:53 PM
|
|
|
|
|
It looks self-explanatory. What part is troubling you?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"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
|
|
|
|
|
What don't you understand specifically ? The code is pretty straightforward to understand: if the call to create the view fails, the function returns -1 
|
|
|
|
|
It probably means you need to read an introductory C++ book (if the syntax confuses you) or an introductory MFC book (if CView is unknown to you)
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Is the cursed number -1, are the strange duplications of the symbols : and =, or, eventually, is the terrible uncertainity conjured up by the if keyword troubling you?
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]
|
|
|
|
|
This is funny. My copy and paste didn't work. I had few lines of code after that were causing an assertion failure...but got it to work.... 
sft
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
