[Bluez-devel] read_RSSI and others not thread-safe?

[Bluez-devel] read_RSSI and others not thread-safe?

[Stefan Mischke]

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

[Bluez-devel] Re: read_RSSI and others not thread-safe?

[Stefan Mischke]

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

Re: [Bluez-devel] Re: read_RSSI and others not thread-safe?

[Marcel Holtmann]

Hi Stefan,

> 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.

there is no pre-filtering for this kind of stuff. Feel free to send in a
patch for checking the connection handle.

Regards

Marcel




-------------------------------------------------------
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

Re: [Bluez-devel] Re: read_RSSI and others not thread-safe?

[Stefan Mischke]

Hi Marcel,

if there is no pre-filtering then a process could open a socket to hci, 
set the event filter to "all events" and receive events which are 
results of other processes/sockets? Is this really true?

Regards
Stefan

Marcel Holtmann schrieb:

>Hi Stefan,
>  
>
>there is no pre-filtering for this kind of stuff. Feel free to send in a
>patch for checking the connection handle.
>
>Regards
>
>Marcel
>
>
>  
>

Re: [Bluez-devel] Re: read_RSSI and others not thread-safe?

[Marcel Holtmann]

Hi Stefan,

> if there is no pre-filtering then a process could open a socket to hci, 
> set the event filter to "all events" and receive events which are 
> results of other processes/sockets? Is this really true?

it is a raw socket and every process can get all events. It is not
possible to prevent this and actually the HCI itself is not designed for
something like this. However you must be root to get some special
events.

Regards

Marcel




-------------------------------------------------------
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

Re: [Bluez-devel] Re: read_RSSI and others not thread-safe?

[Stefan Mischke]

Hi Marcel!

Ok, but I don't understand why my problem occurs. Look at this:
- thread T1 does hci_send_req(read_RSSI), waits for event E1
- thread T2 does hci_send_req(read_RSSI), waits for event E2
- Lets assume E2 comes earlier than E1
Why do BOTH threads receive E2? When is an event consumed?

Regards
Stefan

Marcel Holtmann schrieb:

>Hi Stefan,
>  
>
>it is a raw socket and every process can get all events. It is not
>possible to prevent this and actually the HCI itself is not designed for
>something like this. However you must be root to get some special
>events.
>
>Regards
>
>Marcel
>
>
>  
>

Re: [Bluez-devel] Re: read_RSSI and others not thread-safe?

[Marcel Holtmann]

Hi Stefan,

> Ok, but I don't understand why my problem occurs. Look at this:
> - thread T1 does hci_send_req(read_RSSI), waits for event E1
> - thread T2 does hci_send_req(read_RSSI), waits for event E2
> - Lets assume E2 comes earlier than E1
> Why do BOTH threads receive E2? When is an event consumed?

both are waiting for the next RSSI event and if one occurs both return
with that value. As you already noticed there is no comparison of the
connection handle. All outstanding events are discarded when the socket
descriptor is closed.

Regards

Marcel




-------------------------------------------------------
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