Charm++ parallel programming system

[Jonathan Lifflander <jliffl2 AT illinois.edu>]

I think that "on demand creation" is the solution to the insertion
problem. Basically, instead of calling insert(), you call a method
denoted in the .ci file as causing the element come into existence, if
it doesn't already exist. Hence, you can make many of these calls and
they will be idempotent. I think that deleting and re-inserting is
fine, but you shouldn't delete() or insert() multiple times in a row
(except for "on demand creation" where it is allowed). Calling
delete() on something that is deleted, can cause problems I think.

On your other email chain, you have discovered a bug in the
communication-aware load balancing code, where the graph assumes that
every edge will always have both nodes. This is obviously not true in
the case of deletions and insertions (or even just periodic load
balancing when the state may not be clearly defined). I will try to
have this patched soon.

Thanks very much for spending the time to tell us about the problems
and bugs that you encounter. You are traversing new ground in some
ways, because although we have support for many of these dynamic
operations, it is very much still an open research problem of how to
coordinate them and maintain a stable state across the distributed
system.

Jonathan

On Tue, Aug 27, 2013 at 2:47 PM, Nicolas Bock 
<nicolasbock AT gmail.com>
 wrote:
> Hi Jonathan,
>
> In every iteration of the code, I manipulate a chare array inside the
> reduction of another chare array by insert()'ing or ckDestroy()'ing array
> elements. My thinking was that I probably should not insert or destroy
> elements that already exist, or were destroyed in a previous iteration,
> respectively. If I can't directly inquire the array whether an element
> exists or not, then I need to use an auxiliary bool array to keep track,
> which is somewhat cumbersome because this array needs to be sent around in
> the reduction calls, and then brought back to the caller for the next
> iteration.
>
> Thanks,
>
> nick
>
>
>
> On Mon, Aug 26, 2013 at 10:55 PM, Jonathan Lifflander 
> <jliffl2 AT illinois.edu>
> wrote:
>>
>> Depending on what features you are using, existence may be a very
>> transient properly! For instance, if you call ckDelete() on the
>> element, but it has not arrived, what would you expect the output to
>> be?
>>
>> Can you possibly give more details about your use case?
>>
>> Jonathan
>>
>> On Mon, Aug 26, 2013 at 10:44 PM, Nicolas Bock 
>> <nicolasbock AT gmail.com>
>> wrote:
>> > Hi,
>> >
>> > is it possible to inquire a chare array to test whether a particular
>> > array
>> > element exists or not? Something like
>> >
>> > bool ArrayElement::exists (int x, int y, ...);
>> >
>> > maybe?
>> >
>> > Thanks,
>> >
>> > nick
>> >
>> >
>> > _______________________________________________
>> > charm mailing list
>> > charm AT cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/charm
>> >
>
>