我一直在試驗GNU Radio,並遇到了tunnel.py程序。該程序允許您使用Linux TUN/TAP設備通過無線無線鏈路傳輸IP流量。它的大部分工作正常,但是代碼的一部分讓我感到困惑。我在這裏有線程問題嗎?
有它實現了一個「基本MAC層」的一類。這個類有一個回調函數,它向TUN設備寫入一個新的數據包。此功能(phy_rx_callback
)是從單獨的線程調用的。
功能main_loop
發送新分組之前確實載波偵聽。我不明白的是爲什麼它在單獨的非重疊傳輸通道上傳輸之前感測接收通道。
兩個RX和TX信道是不同的頻率,和我們的硬件允許全雙工通信。
因此,我的問題是與main_loop
執行,異步調用phy_rx_callback
函數的另一個線程的含義是什麼?問題是我試圖瞭解載波檢測循環的目的,我發現評論該代碼會嚴重降低性能。在使用傳輸通道之前,我會監控一個接收通道,實質上將其變爲半雙工,這對我來說沒有任何意義。然後我沒有看到使用兩個頻率的目的,一個用於傳輸,一個用於接收。我開始懷疑在這裏工作是否有一個奇怪的線程問題。
的cs_mac
類的單個實例最初創建。指向rx_callback函數的「指針」向下傳遞給實際調用它的線程類。這裏是cs_mac類:
class cs_mac(object):
def __init__(self, tun_fd, verbose=False):
self.tun_fd = tun_fd # file descriptor for TUN/TAP interface
self.verbose = verbose
self.tb = None # top block (access to PHY)
def set_top_block(self, tb):
self.tb = tb
def phy_rx_callback(self, ok, payload):
if self.verbose:
print "Rx: ok = %r len(payload) = %4d" % (ok, len(payload))
if ok:
os.write(self.tun_fd, payload)
def main_loop(self):
min_delay = 0.001 # seconds
while 1:
payload = os.read(self.tun_fd, 10*1024)
if not payload:
self.tb.send_pkt(eof=True)
break
if self.verbose:
print "Tx: len(payload) = %4d" % (len(payload),)
delay = min_delay
while self.tb.carrier_sensed():
sys.stderr.write('B')
time.sleep(delay)
if delay < 0.050:
delay = delay * 2 # exponential back-off
self.tb.send_pkt(payload)
好,所以使用ctypes.CDLL('libc.so.6').syscall(186))
,要求gettid
我發現線程調用rx_callback
函數具有相同的PID,但不同的TID。
的問題是,什麼是具有一個單獨的線程在主線程(而該線程是不斷循環)調用函數從一個對象的影響是什麼?
不能說我對GNU廣播知道很多,但這裏是我的2美分。只要在GNU Radio端使用不同的資源(無論是軟件還是硬件方面),將TX和RX放在不同的線程中都不會有問題。你說他們使用單獨的頻道,因此聽起來他們可能是分開的。另一方面,他們使用相同的天線,所以你可以真正在同一時間發送和接收? – ktdrv 2011-04-20 22:04:53