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