Skip to contentSkip to conversation

read_RSSI and others not thread-safe?

Bluez-devel Stefan Mischke 2 participants 7 messages Oct 8, 2004 Bluetooth drivers

lore
Share & tools
lore

Stefan Mischke

author
#0 lore raw

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

author
#1 lore raw

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

Quoted 10 lines · 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

maintainer
#2 lore raw

Hi Stefan,

Quoted 7 lines

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

author
#3 lore raw

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

Quoted 13 lines · Marcel Holtmann

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

maintainer
#4 lore raw

Hi Stefan,

Quoted 3 lines

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

author
#5 lore raw

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

Quoted 15 lines · Marcel Holtmann

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

maintainer
#6 lore raw

Hi Stefan,

Quoted 5 lines

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel