[charm] Charm++ & thread in library ?
chaomei2 at illinois.edu
Fri Jun 4 14:12:22 CDT 2010
If you run that program several times in non-SMP mode, you would see the program crashed at pthread_join. If removing the pthread_join, the program may aborted saying "Fatal error on PE 0> unexpected call to exit by user program. Must use CkExit, not exit!".
From: Filippo Gioachin
Sent: Friday, June 04, 2010 1:59 PM
To: Kale, Laxmikant V
Cc: charm at cs.uiuc.edu ; Christian Perez
Subject: Re: [charm] Charm++ & thread in library ?
Well, charm cares about pthreads only in the SMP build. If you build without SMP support, then everything in charm is global, and pthreads can be created by the user.
I tried to build the program using net-linux-amd64 build and it seems to work fine with thread creation. So the easiest option may be to use a non-SMP version of Charm++.
CCS could be used, but each JVM (with the current interface) has to connect to node zero (or charmrun program) to communicate with the application, so it doesn't seem to fit if you want each processor to have a JVM associated with it.
On Fri, Jun 4, 2010 at 12:36, Kale, Laxmikant V <kale at cs.uiuc.edu> wrote:
Gengbin, Isaac: can he use the CCS interface for this? It is meant for external entities to inject messages into Charm++ computations, which is roughly what is happening here-- at least from the invocation point of view.
Laxmikant Kale http://charm.cs.uiuc.edu
Professor, Computer Science kale at illinois.edu
201 N. Goodwin Avenue Ph: (217) 244-0094
Urbana, IL 61801-2302 FAX: (217) 265-6582
> -----Original Message-----
> From: Christian Perez [mailto:christian.perez at inria.fr]
> Sent: Friday, June 04, 2010 11:10 AM
> To: Kale, Laxmikant V
> Cc: charm at cs.uiuc.edu; kale at illinois.edu
> Subject: Re: [charm] Charm++ & thread in library ?
> I was guessing it is not an intended usage. I am going to try an hack
> my code not to invoke
> charm operations from those threads. It it fails, I will try another
> very very ugly hack but should work
> to remove those pthread calls.
> I'll keep you inform.
> On 06/04/2010 04:16 PM, Kale, Laxmikant V wrote:
> > This is not an intended usage, because Charm++ likes to assume
> control of cpus (and a pthread_created will relinquish that control..
> charm creates exactly the number of pthreads as the number of cores (or
> SMTs in some cases) on each node.
> > When you create a new pthread, its going to create ambiguity about
> what the sending "PE" is, for Charm++. Troubles may emanate from that.
> But in principle, I think this can be supported with appropriate
> limitations with some work: it's a question of whether to support such
> a model. (e.g. think about multiple pthreads created in this fashion.
> What global variables can they access? How to ensure thread safety in
> messaging layer underneath?)
> > --
> > Laxmikant Kale http://charm.cs.uiuc.edu
> > Professor, Computer Science kale at illinois.edu
> > 201 N. Goodwin Avenue Ph: (217) 244-0094
> > Urbana, IL 61801-2302 FAX: (217) 265-6582
> >> -----Original Message-----
> >> From: charm-bounces at cs.uiuc.edu [mailto:charm-bounces at cs.uiuc.edu]
> >> Behalf Of Christian Perez
> >> Sent: Friday, June 04, 2010 7:10 AM
> >> To: charm at cs.uiuc.edu
> >> Subject: [charm] Charm++& thread in library ?
> >> Hello,
> >> I'd like to know whether there is a simple solution to the following
> >> situation:
> >> A charm application is using a library that creates threads
> >> (pthread_create).
> >> Those threads would like to invoke methods on charm objects.
> >> When I test it (cf attached file), it bugs. Is it possible to
> >> such a situation or not?
> >> Ugly details: the library is a JVM, but it also fails with simple
> >> as in the attached file.
> >> Thank you!
> >> Christian
charm mailing list
charm at cs.uiuc.edu
Department of Computer Science
University of Illinois at Urbana-Champaign
charm mailing list
charm at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the charm