public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Stefan Mischke <survivor@uni-paderborn.de>
To: Stefan Mischke <survivor@uni-paderborn.de>
Cc: BlueZ Mailing List <bluez-devel@lists.sourceforge.net>
Subject: [Bluez-devel] Re: read_RSSI and others not thread-safe?
Date: Fri, 08 Oct 2004 16:48:56 +0200	[thread overview]
Message-ID: <4166A8D8.3080707@uni-paderborn.de> (raw)
In-Reply-To: <41668ADE.7010004@uni-paderborn.de>

I looked into the code and I think the problem is somewhere inside of 
bluez-libs' "hci_send_req()". The connection handle field of the events 
are not compared to the one from the request. Actually, this should be 
no problem since there shold be some kind of pre-filtering inside the 
kernel by the hci socket. I don't know. It doesn't seem to happen with 
l2cap and so I'll use the "synchronized" workaround (which costs a 
little performance). But if someone finds the problem, I'm interested in it.

Regards
Stefan


Stefan Mischke schrieb:

> Hello!
>
> I've written a small JBlueZ-like JNI-Library which gives Java access 
> to BlueZ. My demo application has one threads for each connection (two 
> at the moment) which concurrently do read_RSSI, 
> read_Transmit_Power_Level and read_Link_Quality. If by random two 
> threads do one, two or all three of these calls at the same time, the 
> result values are equal (although they can't be since one connection 
> is really bad). This doesn't happen if I declace the three functions 
> "synchronized" in the Java part of the JNI. But this should not be 
> necessary, should it? Since my functions only use by-value parameters 
> and local variables, they should be thread-safe. I also figured out 
> that the BlueZ sockets in these calls are unequal, but the result 
> (RSSI value) is equal. Why can this happen?
>
> I wonder if this could also occour on one of the other, more important 
> functions like l2cap_read/write. Any idea? Thanks!
>
> Regards
> Stefan
>
>


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

  reply	other threads:[~2004-10-08 14:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-08 12:41 [Bluez-devel] read_RSSI and others not thread-safe? Stefan Mischke
2004-10-08 14:48 ` Stefan Mischke [this message]
2004-10-08 15:29   ` [Bluez-devel] " Marcel Holtmann
2004-10-08 15:38     ` Stefan Mischke
2004-10-08 15:40       ` Marcel Holtmann
2004-10-08 16:02         ` Stefan Mischke
2004-10-08 16:06           ` Marcel Holtmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4166A8D8.3080707@uni-paderborn.de \
    --to=survivor@uni-paderborn.de \
    --cc=bluez-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox