Charm++ parallel programming system

["Kale, Laxmikant V" <kale AT cs.uiuc.edu>]

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