make all
./manager
- enter the number of active cameras
- then on separate terminal window run
./gpumanager
- the outputs are generated in cameralogs.txt and gpulogs.txt
- to add new camera enter
add
into manager prompt - to remove enter
remove
- to stop enter
stop
- after stop, you should manually halt the gpumanager prompt
- cameraHandler.c
- cameraManager.c
- SimpleGpuManager.c
- dataBlock.h
The purpose of this file is to describe the memory block that will be shared among processes. Let's stop on each variable:
- DataBlock Shared data block. Contains everything the program needs
- numberOfActiveCameras -> it is self explanatory to track number of active cameras that are producing
- commandType -> this is variable that cameraManager uses to signal cameraHandler (more on this further)
- commandIndicator -> this is semaphore to synchronize the access to commandType
- produced -> semaphore, indicates number of produced data. Initially set to 0
- consumed -> semaphore, indicates number of consumed data. Initially set to 20 (MAX_CAM_NUMBER * 2)
- consumedUpTo -> the value of this integer indicates that up to which value of array of camdata gpu already consumed (encoded) (cumulative)
- producedUpTo -> the value indicates that up to which value of array of camdata produced (cumulative)
- cIndexLock, pIndexLock -> semaphore, to sync the access to respective integers
- struct cameraSockets -> the entity that mock camera will use to write data
- struct camData -> the actual camera data, each camData have 60 frames of particular camera.
- cameraID -> id of connected camera
- cameraStatus -> status of the socket (BUSY, ON, OFF)
- gracefullFinishLock -> lock whose purpose is to ensure proper shutdown of the socket. We should not power off in the middle of the writing process.
- allocates shared memory
- get from user initial active camera value
- cooperate with control block of cameraHandler to (ADD, REMOVE, STOP)
- cooperation happens with commandIndicator lock
- we find camera whose status is OFF (here I should mention that, we find it just by iteration, however it is easy to configure so that we can choose which camera to add and remove)
- after that we change its status into ON
- specify the command type
- and add 1 to the semaphore value -> (it acts like a signal for the control block of cameraHandler)
- we find camera whose status is BUSY (here I should mention that, we find it just by iteration, however it is easy to configure so that we can choose which camera to add and remove)
- after that we change its status into OFF
- specify the command type
- and add 1 to the semaphore value -> (it acts like a signal for the control block of cameraHandler)
- then wait for the gracefullShutdown -> only then we can proceed further
It has three parts:
- init block -> to activate cameras initially (number of active cameras that we get from user)
- control block -> with the help of command indicator the block will cooperate with manager
- do something block -> where active camera writes data into allocated blocks
- two GPU encoders
- I've assumed that it will presumably spend 0.2 seconds for 60 frames -> considering 300fps
- It will cooperate with cameraHandlers with just one lock (produced)
- cIndex lock is required to cooperate within those 2 processes