thắc mắc Phân biệt giữa Junior và Senior?
- Người tạo chủ đề girlxinhgai
- Ngày bắt đầu
FighterVn
Senior Member
tôi cũng để ý cái nàyko ăn thua đâu, tôi pv mãi các ông outsource rồi đây, các ông outsource CV thì nhiều buzz word đấy, ừ thì cũng có dùng rồi đấy, nhưng mà dùng kiểu hời hợt, hỏi sâu 1 chút không biết, hỏi troubleshoot thì chưa từng làm, hỏi tại sao dùng thì do khách hàng yêu cầu. Ví dụ các ổng nói các ổng biết Kafka, chỉ cần hỏi 1 chút về partition, message delivery order, offset reset mechanism,... thì khả năng cao là oằn tà là vằn ngay. CV càng nhiều buzz word thường càng dễ quay. Tất nhiên có people this people that, nhưng thống kê của cá nhân tôi từng phỏng vấn thì các ông outsource 2-3 năm hay rơi vào tình trạng hời hợt kiểu này.
CV mà càng nhiều buzz words thì khả năng tạch khi bị xoắn càng cao. Tôi pv mấy người có background bên Consultancy (bên này ko gọi outsource), thì thường có 2 trường hợp1. là guru, siêu giỏi, hỏi gì cũng biết -> dạng này rất rất rất là hiếm
2. là hỏi sơ thì biết, còn xoắn sâu chút thì lại cứng. Kiểu như có xài qua nhưng chỉ là xài thôi chứ ko tìm hiểu sâu, hoặc là ko gặp vấn đề khó để mà đào sâu
nói chung cái tôi hay thấy là người giỏi thì thường ko khoe khoang trong CV, tôi còn từng thấy mấy CV tự chấm điểm Nodejs 9/10, tôi vào hỏi event loop hoạt động ra sao thì cứng, hoặc đơn giản là 1 nodejs project xài mấy thread thì cũng cứng luôn
thành ra rút kinh nghiệm cái này, trong CV tôi, cái nào thực sự hiểu tường tận cỡ 6-7/10 trở lên (theo kiểu 10 là như tác giả luôn) thì mới dám để vào. Như tôi xài k8s tự set up 1 cluster, tự vận hàng, viết manifest rồi scale các kiểu mà ai hỏi cũng chỉ dám nói là biết xài, còn kêu tự chấm thì chắc 4/10 thôi
NgonLuaTrongDem
Member
sinh viên năm 3 vào đọc và lạnh gáy
e nổ cmn não rồi
e nổ cmn não rồi
prescolt
Member
Deadlock đã xãy ra thì làm gì có giải quyết, chỉ có lập trình fix nguyên nhan gay deadlock. Chứ đã deadlock thì biết task nào là nguyên nhân đâu, nó là con rắn tự cắn đuôi rồi. OS xử lí deadlock là ngăn ko cho deadlock làm quá tải hệ thống, chứ ko phải là xử lí lỗi deadlockbạn chia sẽ thêm về vấn đề này được không
mình chưa gặp trường hợp thực tế nào, google thì thấy giải thích khá chung chung
via theNEXTvoz for iPhone
freedom.9
Senior Member
M.S Xuan Dieu
Junior Member
Ơ các cậu ơi, mình coment được vào đây, nghĩa là mình cmt vào được tất cả các Thread trong f17 và f33 rồi phải không nhỉ 
Ôi vui quá xá :sexy:
Ôi vui quá xá :sexy:
BetterNextTime
Senior Member
Sai. Deadlock Detection là cho phép Deadlock xảy ra rồi trace rồi sửa nhé. https://docs.microsoft.com/en-us/wi...dlock-detection#monitoring-deadlock-detectionDeadlock đã xãy ra thì làm gì có giải quyết, chỉ có lập trình fix nguyên nhan gay deadlock. Chứ đã deadlock thì biết task nào là nguyên nhân đâu, nó là con rắn tự cắn đuôi rồi. OS xử lí deadlock là ngăn ko cho deadlock làm quá tải hệ thống, chứ ko phải là xử lí lỗi deadlock
via theNEXTvoz for iPhone
prescolt
Member
Ko thấy tôi ghi là lập trình fix dead lock à, ko phải là thằng viết code là thằng nào? mà sai với đúng. Fix deadlock thì ko trace thì có công cụ nào khác mà phải nói nhu phát kiến vậy. Java thì dump mem, c thì strace, coredump. Mic ko viết ko biết. Làm quái gì có cái os nào ngăn việc xay ra deadlock ? Ngoài việc nhận diện thì có os ngăn ngừa deadlock a ?
via theNEXTvoz for iPhone
BetterNextTime
Senior Member
Anh nói sai khi anh bảo không biết task nào là nguyên nhân. Nó là circular dependecy nhưng số task là hữu hạn và build đc cyclic graph chứ không thể dùng hình tượng con rắn cắn đuôi được.
Tôi không bảo là phát kiến gì, chỉ update kiến thức cho đúng thôi.
Deadlock detection là để trace lại rồi tìm ra nguyên nhân deadlock, từ đó mới fix được. Nếu không biết task nào violate thì làm sao fix? Bản thân OS cung cấp công cụ để cho anh fix rồi không cần lập trình lại nếu là Deadlock detection
Có OS đã đc xấy dựng và chứng mình không thể xảy ra deadlock rồi nhé. Anh tự google với Wiki đi.
prescolt
Member
Tôi nói ko biết task nào là nguyên nhân khi có deadlock xãy ra, khi một chương trình deadlock , việc này có gì phải bàn cãi?. Vậy nên mới cần lập trình viên fix, và fix thì dump mem. Tôi thấy anh dang hiểu sai đê nâng tầm anh lên thôi. Toii thừa biết deadlock là gì, xủ lí nó ra sao. Cần gì phải search google. Con rắn căn đuôi mô phỏng cho vòng lặp của deadlock thôi mà có gì ko đúng. Với tôi thấy anh dang có vấn dề đọc hiểu, kiểu như anh tự đặt vấn đề cho là người khác ko biết xong muốn thông não cho ngươi khác vấn đề anh tự đưa ra . Chỗ nào tôi nói deadlock cần lập trình lại os ? Anh tự nhét chữ xong lại đòi thông não là sao ?
via theNEXTvoz for iPhone
Sửa lần cuối:
BetterNextTime
Senior Member
Anh bảo anh thừa biết deadlock là gì. Vậy mà ngay câu đầu tiên
Tôi nói ko biết task nào là nguyên nhân khi có deadlock xãy ra.
Nguyên nhân xảy ra deadlock là do cả 4 điều kiện deadlock đồng thời thỏa mãn nhé anh. Và tổng kết ngắn gọn là các processes (tasks) ở trạng thái chờ vì resources bị locked và không thể share, tạo thành sự phụ thuộc vòng tròn.
Tôi chỉ lấy lời của anh chứ có nhét chữ gì. Nếu tôi hiểu sai thì anh thông cảm chỉ ra.
prescolt
Member
Dead lock hoàn toàn ko đề cập tới task gây ra deadlock. Không đề cập tới task gây ra dead lock vậy người vận hành tìm task là vô nghĩa. Task ko phải nguyên nhân, nó là kết quả. Xử lí deadlock người ta xem thời điểm coredump, tài nguyên nào đang bị chiếm giữ tại thời điểm đó chứ anh tìm task làm gì vậy ? Anh lấy lí thuyết thỏa 4 điều kiện đó ra xem mà không đọc nó đề cập tới vấn đề gì à ?
/Edit
Tôi cho 1 ví dụ haproxy phiên bản gần dây deadlock khi thêm acl IP thông qua unix socket. Và máy chủ 1 thời điểm có ko biết bao nhiêu task add acl vào qua unix socket. Khi bi deadlock, có task set server parameter chạy đồng thời . Vậy theo anh thằng nào là nguyên nhân gây ra deadlock ? nếu theo lí luận của anh đi là tìm task gây ra nguyên nhân ? set server backend parameter hay add acl vào server ?.
Sửa lần cuối:
manhhuy02
Senior Member
chủ thớt thông minh vl, trước khi đi pv lên voz bait một phát là có ngay 1 đống anh tài vào, lấy được mớ thông tin ôn luyện.
Nhớ có topic gì trên reddit nói là khi đặt câu hỏi trên stackoverflow thì nên log acc clone vào trả lời bậy bạ, thì tức khắc có đứa nhảy vào chỉnh bạn ngày và cho câu trả lời đúng, đơn giản vì họ muốn chứng minh là mình đúng
Nhớ có topic gì trên reddit nói là khi đặt câu hỏi trên stackoverflow thì nên log acc clone vào trả lời bậy bạ, thì tức khắc có đứa nhảy vào chỉnh bạn ngày và cho câu trả lời đúng, đơn giản vì họ muốn chứng minh là mình đúng
prescolt
Member
ANh viết như thế này chứng tỏ anh ko hiểu gì về dead lock, chỉ là lí thuyết và chưa bao giờ gặp trong hệ thống . Nói như này thi OS xử lí hết deadlock rồi, lập trình ứng dụng ngu cũng không gặp dead lock ?
BetterNextTime
Senior Member
@prescolt
Anh bảo tìm resource bị chiếm giữ tại thời điểm đó thì anh tìm thế nào? Chẳng phải thông qua các waiting task tại thời điểm đó à?
Hay là chỉ dựa trên việc resource bị hold mà anh biết được nó gây ra deadlock? Lỡ đâu có 1 long time background process giữ nó thì sao? Tôi không rành low level nên mong anh thông não giúp chỗ này.
Trở về vấn đề haproxy, dựa trên kiến thức lý thuyết thì tôi thấy cần làm thế này
trước hết cần phải reproduce được deadlock. Sau đó sẽ biết được deadlock ở task nào. vì các task đều waiting nên cpu sẽ lên cao. khi biết task nào thì mới tìm xuống phân tích là nó access resource nào rồi mới xem cái dependecy nó ở đâu.
Đây là tôi dựa trên lí thuyết chứ tôi không dùng haproxy đã 2 năm rồi nên không thể nói cụ thể được. Nếu anh có link lỗi cho tôi xin để đọc thêm.
Anh bảo tìm resource bị chiếm giữ tại thời điểm đó thì anh tìm thế nào? Chẳng phải thông qua các waiting task tại thời điểm đó à?
Hay là chỉ dựa trên việc resource bị hold mà anh biết được nó gây ra deadlock? Lỡ đâu có 1 long time background process giữ nó thì sao? Tôi không rành low level nên mong anh thông não giúp chỗ này.
Trở về vấn đề haproxy, dựa trên kiến thức lý thuyết thì tôi thấy cần làm thế này
trước hết cần phải reproduce được deadlock. Sau đó sẽ biết được deadlock ở task nào. vì các task đều waiting nên cpu sẽ lên cao. khi biết task nào thì mới tìm xuống phân tích là nó access resource nào rồi mới xem cái dependecy nó ở đâu.
Đây là tôi dựa trên lí thuyết chứ tôi không dùng haproxy đã 2 năm rồi nên không thể nói cụ thể được. Nếu anh có link lỗi cho tôi xin để đọc thêm.
BetterNextTime
Senior Member
Tôi nói là xử lý có gì sai. Nếu như hệ điều hành tự có deadlock detection và tự fix đc (như link windows) tôi đưa ra trên chẳng hạn.
Ứng dụng của anh chạy ngu nhưng hệ điều hành vẫn detect đc và bắt anh reboot. Hoặc nếu là prevention thì nó không cho anh start cái process ấy.
prescolt
Member
Deadlock thì thằng nào chẳng waiting vậy anh ?, nguyên 1 đám task trong thread đang waiting, làm toàn bộ các task còn lại dính chùm. Anh nói tìm task gây ra nguyên nhân, vậy nguyên 1 đám đang bị lock, vậy thằng nào là nguyên nhân của thằng nào ? Đã deadlock còn tìm task ? Lại còn giả lập lại nó? Anh có bao giờ đi xử lí deadlock chưa vậy. Chẳng có ai có thể giả lập duoc khi xãy ra deadlock, biết nguyên nhân nào gây ra mà đi giả lập ? . Người ta cho nó chạy tiếp tục như bình thường, cấu hình kernel ghi coredump của tiến trình ra file. Dùng tool dể đọc cái cục memory lúc đó lên rồi xử lí. Deadlock có phải bug logic éo đâu mà giả lập lại. Anh tóm lại là chỉ có vừa tranh luận vừa search google thôi chứ đã bao giờ xử lí đâu. Tôi đọc qua là hiểu.
prescolt
Member
Làm gì có OS nào tự xử lí duoc deadlock. Môn hệ điều hành ở đại học dạy deadlock, người ta chỉ nói model của nó. Thằng OS tốt là thằng OS khi ứng dụng thứ cấp chay deadlock, gây loop mở ra nhiều thread, nó phát hiện ra và cho dump ứng dụng. Đó là cách unix hay windows xử lí deadlock, xử lí là ngăn pannic chứ ko phải xử lí là ngăn không cho nó xãy ra deadlock. Các giải pháp ngăn ko xãy ra các điều kiện deadlock là model của lập trình chứ ko phải là OS nó làm theo mấy cái đó để ngăn phần mềm thứ cấp deadlock. Kiến thức hệ thống của anh nói chung có vấn đề.
BetterNextTime
Senior Member
Tôi đúng là có google HAproxy để đọc thêm. Còn mấy cái ở trên là dựa trên lý thuyết OS. Đúng là tôi chưa xử lý deadlock nhiều sâu đến OS level nên có thể không bằng anh.
Tôi có 1 ý là nếunhuw tình huống deadlock xảy ra anh cũng có traffic log hoặc snapshot của hệ thống. Hơn nữa nếu là nếu anh bring 1 cái hệ thống khác tương tự lên chạy với cái live traffic thì nó phải xảy ra deadlock lại chứ?
Tôi hỏi để hiểu thêm chứ không phải nói anh sai. Vì lí thuyết tôi mang ra áp dụng có thể áp dụng sai
BetterNextTime
Senior Member
Như đi học môn OS có đề cập tới Deadlock Prevention. Như vậy vẫn cod thể xây dựng 1 hệ điều hành đểngawn không xảy ra deadlock nhỉ? (tất nhiên là sẽ tradeoff)
Tôi đồng ý với anh là OS cung cấp giải pháp ngăn panic bằng cách detect deadlock. Nhưng trong docs của microsoft nó nói rõ ràng là expose ra tasks trace để check. Hơn nữa 1 task waiting và consume nhiều cpu thì nó hiển thị qua ví dụ top (tôi ko rành trên windows cmd check thế nào) chứ đâu phải tất cả các task đều giống nhau?
