Skip to Content.
Sympa Menu

charm - Re: [charm] zhenggb@gmail.com

charm AT lists.cs.illinois.edu

Subject: Charm++ parallel programming system

List archive

Re: [charm] zhenggb AT gmail.com


Chronological Thread 
  • From: Phil Miller <mille121 AT illinois.edu>
  • To: 倪安宁 <nianning1981 AT 163.com>
  • Cc: charm AT cs.uiuc.edu
  • Subject: Re: [charm] zhenggb AT gmail.com
  • Date: Wed, 3 Mar 2010 10:25:03 -0600
  • List-archive: <http://lists.cs.uiuc.edu/pipermail/charm>
  • List-id: CHARM parallel programming system <charm.cs.uiuc.edu>

2010/3/3 倪安宁
<nianning1981 AT 163.com>:
>   I have got from the charm++ programming language manual that “Every
> CHARM++ program must have at least one mainchare, Each mainchare is created
> by the system on processor 0 when the CHARM++ program starts up”. However, I
> am confused with the following question:
>
> I have developed a GUI program called “mytest” based on MFC and declared a
> charm++ class named “myMain” in my GUI program. However, I specified the
> class myMain as the mainchare in my .ci file. But when the GUI program
> starts up, the constructor and function InitInstance() of class CmytestApp
> will be executed firstly, not the constructor of class myMain. The I invoked
> myMain::ckNew( )  in the constructor of CmytestApp, but when run to the
> ckNew() the error occurred: “Unhandled exception at 0x004bc83e in
> mytest.exe: 0xC0000005: Access violation reading location 0x00000000.”
>
> I want to know which class should been specified as the mainchare in .ci
> file on earth, CmytestApp or myMain?
>
>  If CmytestApp, how should I declare the CmytestApp class,
>
> class CmytestApp : public CWinApp, public Chare
>
> {}
>
>  Or
>
>  class CmytestApp : public Chare, public CWinApp
>
> {}

Hi Anning,

I don't know MFC at all, but I suspect you probably shouldn't conflate
its program entry point ('main' function) with that of your Charm++
code. You'll need one to call the other. Since I know Charm++ needs
its own customized startup routines, you should see if it's possible
to have one processor call your MFC main once Charm has started itself
up. The best way I can think of to do this is a threaded entry method
on a group, so that you can ensure that the processor running the GUI
code is one that's actually hooked up to a display. Note that Charm's
threading model is entirely cooperative, not preemptive, so this
processor will not be able to run computation generated by entry
method invocations unless you jump through some hoops (possibly just
calling CthYield(), but possibly more effort).

Best of luck!

Phil





Archive powered by MHonArc 2.6.16.

Top of Page