Charm++ parallel programming system

[Filippo Gioachin <gioachin AT uiuc.edu>]

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.

Filippo

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.

Sanjay

--
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
> in
> 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.
>
> Christian
>
> 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]
> On
> >> 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
> support
> >> such a situation or not?
> >>
> >> Ugly details: the library is a JVM, but it also fails with simple
> example
> >> as in the attached file.
> >>
> >> Thank you!
> >>
> >> Christian
> >>


_______________________________________________
charm mailing list
charm AT cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/charm

-- 
Filippo Gioachin
PhD Candidate
Department of Computer Science
University of Illinois at Urbana-Champaign
Ph: +1-217-333-4764