[BIOSAL] Causality and ACTION_STOP

[Boisvert, Sebastien]

> From: George K. Thiruvathukal [gkt at cs.luc.edu]
> Sent: Wednesday, November 26, 2014 10:11 AM
> To: Boisvert, Sebastien
> Subject: Re: Causality and ACTION_STOP
> 
> 
> 
> 
> Hi Seb,
> 
> 
> See below!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Wed, Nov 26, 2014 at 10:03 AM, Boisvert, Sebastien 
> <boisvert at anl.gov> wrote:
> 
> 
> > I am looking at spate_metagenome_assembler/spate.c but don't see any usage of core_map. I did see a usage of core_map in argonnite.c, but the map is not actually being sent in a message, AFAICT. :)
> 
> Spate uses the BioSAL actor library in genomics/
> 
> Check out genomics/assembly/assembly_graph_store.c line 494
> 
> 
> 
> 
> 
> ​This looks like the magic formula! I didn't look too closely at the inclusion list.
> 
> 

This is basically the same pattern used in thorium_actor_send_vector.

So you can just take that as a starting point for thorium_actor_send_map.

> 
>     new_count = core_map_pack_size(&concrete_self->coverage_distribution);
>     new_buffer = thorium_actor_allocate(self, new_count);
>     core_map_pack(&concrete_self->coverage_distribution, new_buffer);
> 
>     printf("SENDING %s/%d sends map to %d, %d bytes / %d entries\n",
> 
>                         thorium_actor_script_name(self),
>                     thorium_actor_name(self),
>                     customer, new_count,
>                     (int)core_map_size(&concrete_self->coverage_distribution));
> 
>     thorium_message_init(&new_message, ACTION_PUSH_DATA, new_count, new_buffer);
>     thorium_actor_send(self, customer, &new_message);
> 
> 
>     thorium_message_destroy(&new_message);
> 
> 
> 
> 
> :-) Thanks!
> 
> 
> 
> 
> If we do thorium_message_destroy(), does it also free the underlying buffer?
> 
> ​
> 

No.

thorium_message_destroy() does not free any memory because
thorium_message_init() does not allocate any memory neither.

I guess this is just because I use to do more C++.

> 
> >
> >
> > I'm planning to add these functions to make sending/receiving maps easy.
> 
> That a good idea. I like it.
> 
> 
> 
> ​Great! I will give myself this task. I'm going to end up figuring everything out as part of the new version of hello_acq.c.
> 
> I want maps primarily because I am mapping an actor name to its (boolean) status of having been greeted or not.

This makes sense.

Also, for your information, core_map can never be full although it uses a hash table for the implementation.

Here is the hierarchy:

- core_set is implemented on top of core_map
- core_map is implemented on top of core_dynamic_hash_table (dynamic hash table uses incremental resizing, so it can never be full and
                all calls are still O(1) because of amortization.)
- core_dynamic_hash_table is implemented on top of core_hash_table (hash_table uses double hashing / open addressing)
- core_hash_table is implemented on top of core_hash_table_group (right now, there is 1 group per table, but this could be use to
                implement a sparse container like in Google Sparse Hash Table based on Donald Knuth's algorithm for that).

> 
> ​
> 
> 
> > Similar to your view, I think lists and maps are among the most important collections.
> 
> There is the free_list structure, but it is only used in memory management right now.
> 
> > I once read a paper that most of the reuse in OOP comes from lists and associative structures.
> 
> When you say lists, does that include vector. Usually, vector means array and list means
> linked list.
> 
> 
> 
> ​Yes, it does in an evolutionary sense. I tend to think of vector and lists as being connected. In modern programming libraries, you often see the interfaces conflated (i.e. lists have array-like interfaces and vice versa). Java Vector is kind of an interesting
>  case study!

But a Java ArrayList<Integer> has O(1) random access but can trigger a resize of capacity on insertion which is O(n).

A Java LinkedList<Integer> has O(n) random access but has O(1) insertion.

Sure, both implement the List<Integer> interface, but each has a better use case anyway.


> 
> 
> ​TTYL,
> George
> 
> 
>