hama-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bowers, Richard S." <RICHARD.S.BOW...@saic.com>
Subject Re: [jira] [Updated] (HAMA-546) Add access to remote memory
Date Sun, 13 May 2012 18:22:46 GMT

----- Original Message -----
From: hama-dev-return-7578-RICHARD.S.BOWERS=saic.com@incubator.apache.org <hama-dev-return-7578-RICHARD.S.BOWERS=saic.com@incubator.apache.org>
To: hama-dev@incubator.apache.org <hama-dev@incubator.apache.org>
Sent: Sun May 13 11:58:49 2012
Subject: [jira] [Updated] (HAMA-546) Add access to remote memory

     [ https://issues.apache.org/jira/browse/HAMA-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Thomas Jungblut updated HAMA-546:

    Attachment: HAMA-546_1.patch

First API scratch of how it should look like.

I think we should have multiple "CacheServices" each with generic key and value, each cache
service is identifiable via a String name. 

Every service instantiated will be managed by the CacheHandler (maybe we can rename to CacheManager
to be consistent with sync and messaging).

Then there are concurrent caches and normal caches.

The first patch includes just a rough implementation of normal caches with a map and a queue.

Currently I am not sure whether we should put the CacheHandler into the Peer or into the MessageManager,
but I think the Peer should be the best decision.

As an example of put and get we should add the realtime usage in our wiki.
> Add access to remote memory
> ---------------------------
>                 Key: HAMA-546
>                 URL: https://issues.apache.org/jira/browse/HAMA-546
>             Project: Hama
>          Issue Type: New Feature
>          Components: bsp core
>            Reporter: Thomas Jungblut
>            Assignee: Thomas Jungblut
>         Attachments: HAMA-546_1.patch
> bsp_get and bsp_put are integral parts of the BSP computing model.
> They are defined as follows:
> bsp_get [1]
> {quote}
>      The bsp_get(3) and bsp_hpget(3) operations  reach  into  the
>      local   memory   of  another  process  and  copy  previously
>      registered remote data held there into a data  structure  in
>      the local memory of the process that initiated them.
> {quote}
> bsp_put [2]
> {quote}
>      The aim of bsp_put(3) and  bsp_hpput(3)  is  to  provide  an
>      operation  akin  memcpy(3C) available in the Unix <string.h>
>      library.  Both operations copy a specified number of  bytes,
>      from  a byte addressed data structure in the local memory of
>      one process into contiguous memory locations  in  the  local
>      memory of another process. The distinguishing factor between
>      these operations is provided by the buffering choice.
> {quote}
> A very simple implementation can be based on a HashMap on every peer which can be obtained
via RPC. 
> In this case we need to extend the MessageManager to be able to do off-the-band communication.
> It would be great to extract a common interface which can be inter-operable with other
caching tools like DirectMemory or EHCache. 
> [1] http://www.bsp-worldwide.org/implmnts/oxtool/man/bsp_get.3.html
> [2] http://www.bsp-worldwide.org/implmnts/oxtool/man/bsp_put.3.html

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message