JNI and global variables in shared libs

Discussion in 'Java' started by Drazen Gemic, Oct 21, 2005.

  1. Drazen Gemic

    Drazen Gemic Guest

    This might not be the correct newsgroup for this question, but I am just
    not sure. I need some starting point.

    I am trying to call some third party C code via JNI. It appears to be
    working. The operating system is Linux. Third party code was meant to
    be a command line program, but I managed to create shared library.

    The code is huge, spread across multiple ".c" and ".h" files, and I
    wonder is it thread safe, because Java code will be multithreaded. The
    questions are:

    - if it contains global variables do all threads share the same instance
    of the global C variable, or they are "per thread" ?

    - if it contains global static C variables do all threads share the same
    instance of the global C variable, or they are "per thread" ?

    - what about static C variables in C functions ?

    thanks in advance

    DG
     
    Drazen Gemic, Oct 21, 2005
    #1
    1. Advertising

  2. Drazen Gemic

    Roedy Green Guest

    On Fri, 21 Oct 2005 23:08:28 +0200, Drazen Gemic <>
    wrote or quoted :

    >The code is huge, spread across multiple ".c" and ".h" files, and I
    >wonder is it thread safe, because Java code will be multithreaded. The
    >questions are:
    >
    >- if it contains global variables do all threads share the same instance
    > of the global C variable, or they are "per thread" ?
    >
    >- if it contains global static C variables do all threads share the same
    >instance of the global C variable, or they are "per thread" ?
    >
    >- what about static C variables in C functions ?


    The way to handle this is with synchronized Java methods wrapping the
    native methods that let only one thread at a time into the C side.

    If your C code has some totally independent parts, you can control
    access separately so that you could have two threads on the C side at
    a time, but not both in the same C code section.

    Once that is all working, and only if things are too slow, you might
    look into how to make some parts of the C code thread safe, or how to
    partition the C code into smaller independent sections.

    In the long term, you might gradually bring over crucial functionality
    from the C side to the Java side for ease of maintenance and easier
    thread integration.

    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
     
    Roedy Green, Oct 22, 2005
    #2
    1. Advertising

  3. "Roedy Green" <> wrote:
    >
    > The way to handle this is with synchronized Java methods wrapping the
    > native methods that let only one thread at a time into the C side.
    >

    Why not simply declare the native methods synchronized, for example:
    native synchronized void someMethod();
    thus omitting the mentioned wrapping Java methods?
    --
    "TFritsch$t-online:de".replace(':','.').replace('$','@')
     
    Thomas Fritsch, Oct 22, 2005
    #3
  4. Drazen Gemic

    Roedy Green Guest

    On Sat, 22 Oct 2005 04:55:38 +0200, "Thomas Fritsch"
    <> wrote or quoted :

    >Why not simply declare the native methods synchronized, for example:
    > native synchronized void someMethod();
    >thus omitting the mentioned wrapping Java methods?


    The reason I would done that it is to ensure it was not my problem to
    deal with the synchronisation on the C side where it would be messier.
    It would be just one less uncertainty. I like to do as much as
    possible on the Java side.

    I often make native functions private so that I could reimplement
    them more easily partitioning the work differently for the Java/C
    side on different platforms. I have a wrapper anyway.

    An example would be this code to get the Windows last accessed file
    time in Java format.

    /**
    * get last access date of a file. This may be 2 hours out of date
    since
    * windows does not attempt to keep immediately up to date.
    *
    * @param filename
    * Name of file to request date on.
    * @return Java timestamp when file was last accessed, 0 = problem
    */
    public static long getFileLastAccessed ( String filename )
    {
    long whenFileLastAccessed = nativeGetFileLastAccessed(
    filename );
    return whenFileLastAccessed == 0 ? 0 : ( whenFileLastAccessed
    / 10000 )
    - diffInMillis;
    }

    where nativeGetFileLastAccessed is private.


    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
     
    Roedy Green, Oct 22, 2005
    #4
  5. Drazen Gemic

    Chris Uppal Guest

    Drazen Gemic wrote:

    > - if it contains global variables do all threads share the same instance
    > of the global C variable, or they are "per thread" ?
    >
    > - if it contains global static C variables do all threads share the same
    > instance of the global C variable, or they are "per thread" ?
    >
    > - what about static C variables in C functions ?


    You have correctly identified the features of C/C++ code that are inherently
    not thread-safe.

    If you use any of those features in threaded code then you have to take
    additional steps to ensure that no two threads can ever access them at the same
    time. You could do that in your "glue" code (the JNI DLL) using OS-specific
    features to ensure thread safety (semaphores, mutexes, and so on), or you can
    use Java's synchronisation to the same effect. Using Java's features is
    simplest, but it may not easily provide as much fine-grained control to allow
    you to maximise the concurrent use of your C code (e.g if there are two
    functions that /don't/ share data hen you can safely call them both at the same
    time in different threads). Others have already talked about how to do that in
    Java; I only want to add that you should ensure that all the "synchronized"
    methods are actually invoked on the /same/ object or else the Java runtime
    won't realise that there is any reason to stop two threads running your code at
    the same time. Another way to get the same effect is to make all (no
    exceptions!) the native methods "static" (and synchronised) so that they all
    synchronise on the class object.

    BTW, you should also ensure that your C DLL is liked with a version of the
    C/C++ runtime library (for malloc() etc) that has been written to be
    thread-safe. You may already have done that, or -- for all I know -- the Linux
    libraries may all be inherently threadsafe, but it's worth mentioning, just in
    case...

    -- chris
     
    Chris Uppal, Oct 22, 2005
    #5
  6. Drazen Gemic

    Drazen Gemic Guest

    Thank you all. I have some more information, now.

    Yes, the code is by all means thread unsafe, I have tried to run it from
    a couple threads.

    I can not run the code as a synchronized section of the application,
    because the application is multithreaded server, and it is going to
    be to slow if the clients are processed one at the time. There might
    be some timeouts due to irregular conditions on the network, and all
    other clients would have to wait when it happens.

    I will have to run the code as a separate processes executed from the
    threads. I had some problems even with that (UDP ports, packet ID's),
    but I have modified C the code.

    The code is radius PAP to EAP-TTLS bridge, a piece of middleware between
    old Cisco access server and Radius proxy server.

    DG
     
    Drazen Gemic, Oct 22, 2005
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Imran Aziz
    Replies:
    1
    Views:
    556
    Stefan
    Aug 22, 2005
  2. Christoph
    Replies:
    2
    Views:
    548
    Richard Bos
    Sep 17, 2003
  3. Raman
    Replies:
    5
    Views:
    1,081
    Raman
    May 9, 2008
  4. Replies:
    1
    Views:
    1,306
    santosh
    Jul 15, 2008
  5. Greg Hauptmann
    Replies:
    4
    Views:
    216
    Stefano Crocco
    Feb 7, 2009
Loading...

Share This Page