Lập trình hàm: ý tưởng đúng về đồng thời và trạng thái?

Những người đề xuất FP đã tuyên bố rằng đồng thời là dễ dàng bởi vì mô hình của họ tránh được trạng thái có thể thay đổi. Tôi không hiểu

Hãy tưởng tượng chúng ta đang tạo ra một dungeon thu thập dữ liệu nhiều người chơi (một roguelike) bằng cách sử dụng FP trong đó chúng ta nhấn mạnh các hàm thuần túy và các cấu trúc dữ liệu bất biến. Chúng tôi tạo ra một hầm ngục bao gồm các phòng, hành lang, anh hùng, quái vật và cướp bóc. Thế giới của chúng ta thực sự là một biểu đồ đối tượng của các cấu trúc và các mối quan hệ của chúng. Khi mọi thứ thay đổi, đại diện của chúng ta về thế giới được sửa đổi để phản ánh những thay đổi đó. Anh hùng của chúng ta giết một con chuột, nhặt một thanh kiếm ngắn, v.v.

Đối với tôi thế giới (thực tế hiện tại) mang ý tưởng về nhà nước này và tôi đang thiếu cách mà FP vượt qua điều này. Khi anh hùng của chúng ta hành động, các chức năng sửa đổi trạng thái của thế giới. Dường như mọi quyết định (AI hoặc con người) cần phải dựa trên trạng thái của thế giới như hiện tại. Chúng ta sẽ cho phép đồng thời ở đâu? Chúng ta không thể có nhiều quy trình đồng thời củng cố trạng thái của thế giới kẻo một quá trình dựa trên kết quả của nó trên một số trạng thái đã hết hạn. Tôi cảm thấy rằng tất cả các điều khiển nên xảy ra trong một vòng điều khiển duy nhất để chúng tôi luôn xử lý trạng thái hiện tại được biểu thị bằng biểu đồ đối tượng hiện tại của chúng ta về thế giới.

Rõ ràng có những tình huống hoàn toàn phù hợp cho sự tương tranh (tức là khi xử lý các tác vụ bị cô lập có trạng thái độc lập với nhau).

Tôi không thấy làm thế nào đồng thời là hữu ích trong ví dụ của tôi và đó có thể là vấn đề. Tôi có thể đang trình bày sai về yêu cầu nào đó.

Ai đó có thể đại diện tốt hơn cho tuyên bố này?

Tôi sẽ cố gắng gợi ý về câu trả lời. Đây không phải là một câu trả lời, chỉ là một minh họa giới thiệu. Câu trả lời của @ jk chỉ ra đồ thật, khóa kéo.

Hãy tưởng tượng bạn có một cấu trúc cây bất biến. Bạn muốn thay đổi một nút bằng cách chèn một con. Kết quả là bạn có được một cây hoàn toàn mới.

Nhưng hầu hết cây mới giống hệt cây cũ. Một triển khai thông minh sẽ sử dụng lại hầu hết các đoạn cây, con trỏ định tuyến xung quanh nút bị thay đổi:

Cuốn sách của Okasaki có đầy đủ các ví dụ như thế này.

Vì vậy, tôi cho rằng bạn có thể thay đổi hợp lý các phần nhỏ trong thế giới trò chơi của mình mỗi lần di chuyển (nhặt một đồng xu) và chỉ thực sự thay đổi các phần nhỏ trong cấu trúc dữ liệu thế giới của bạn (ô nơi nhặt đồng xu). Các bộ phận chỉ thuộc về các tiểu bang trong quá khứ sẽ được thu gom rác kịp thời.

Điều này có thể có một số xem xét trong việc thiết kế cấu trúc thế giới trò chơi dữ liệu theo một cách thích hợp. Thật không may, tôi không có chuyên gia trong những vấn đề này. Chắc chắn nó phải là một cái gì đó khác với ma trận NxM mà người ta sẽ sử dụng làm cấu trúc dữ liệu có thể thay đổi. Có lẽ nó nên bao gồm các mảnh nhỏ hơn (hành lang? Các ô riêng lẻ?) Chỉ vào nhau, như các nút cây làm.

Câu trả lời của 9000 là một nửa câu trả lời, cấu trúc dữ liệu liên tục cho phép bạn sử dụng lại các phần không thay đổi.

Bạn có thể đã suy nghĩ tuy nhiên "này, nếu tôi muốn thay đổi gốc của cây thì sao?" vì nó đứng với ví dụ đã cho rằng bây giờ có nghĩa là thay đổi tất cả các nút. Đây là nơi dây kéo đến để giải cứu. Chúng cho phép phần tử tại tiêu điểm được thay đổi trong O (1) và tiêu điểm có thể được di chuyển bất cứ nơi nào trong cấu trúc.

Điểm khác với khóa kéo là Zipper tồn tại khá nhiều loại dữ liệu bạn muốn

Các chương trình kiểu chức năng tạo ra rất nhiều cơ hội như thế để sử dụng đồng thời. Bất cứ khi nào bạn chuyển đổi hoặc lọc hoặc tổng hợp một bộ sưu tập, và mọi thứ là thuần túy hoặc không thay đổi, sẽ có cơ hội cho hoạt động được tăng tốc bởi sự tương tranh.

Ví dụ: giả sử bạn thực hiện các quyết định AI độc lập với nhau và không theo thứ tự cụ thể. Họ không thay phiên nhau, tất cả họ đưa ra quyết định đồng thời và sau đó thế giới tiến bộ. Mã có thể trông như thế này:

func MakeMonsterDecision curWorldState monster =
    ...
    ...
    return monsterDecision

func NextWorldState curWorldState =
    ...
    let monsterMakeDecisionForCurrentState = MakeMonsterDecision curWorldState
    let monsterDecisions = List.map monsterMakeDecisionForCurrentState activeMonsters
    ...
    return newWorldState

Bạn có một chức năng để tính toán những gì một con quái vật sẽ làm cho một trạng thái thế giới, và áp dụng nó cho mọi quái vật như là một phần của tính toán trạng thái thế giới tiếp theo. Đây là một điều tự nhiên phải làm trong một ngôn ngữ chức năng và trình biên dịch có thể tự do thực hiện song song việc áp dụng nó cho mọi quái vật.

Trong một ngôn ngữ bắt buộc, bạn sẽ có nhiều khả năng lặp đi lặp lại trên mọi quái vật, áp dụng hiệu ứng của chúng cho thế giới. Làm điều đó dễ dàng hơn bởi vì bạn không muốn đối phó với việc nhân bản hoặc răng cưa phức tạp. Trình biên dịch không thể thực hiện các tính toán quái vật song song trong trường hợp đó, bởi vì các quyết định quái vật sớm ảnh hưởng đến các quyết định quái vật sau này.

Lắng nghe một vài cuộc nói chuyện của Rich Hickey - đặc biệt là cuộc nói chuyện này - đã làm giảm bớt sự nhầm lẫn của tôi. Trong một lần, ông chỉ ra rằng không sao khi các quy trình đồng thời có thể không có trạng thái hiện tại nhất. Tôi cần nghe đó. Điều tôi gặp khó khăn trong việc tiêu hóa là các chương trình sẽ thực sự ổn với các quyết định dựa trên các ảnh chụp nhanh về thế giới đã bị thay thế bởi các chương trình mới hơn. Tôi cứ tự hỏi làm thế nào mà FP đồng thời xoay quanh vấn đề dựa trên các quyết định dựa trên tình trạng cũ.

Trong một ứng dụng ngân hàng, chúng tôi sẽ không bao giờ muốn đưa ra quyết định dựa trên ảnh chụp nhanh trạng thái đã được thay thế bởi một cái mới hơn (đã xảy ra rút tiền).

Sự đồng thời đó là dễ dàng bởi vì mô hình FP tránh trạng thái có thể thay đổi là một yêu cầu kỹ thuật không cố gắng nói bất cứ điều gì về giá trị logic của các quyết định dựa trên trạng thái tiềm năng cũ. Cuối cùng, FP vẫn thay đổi mô hình nhà nước. Không có xung quanh này.

Những người đề xuất FP đã tuyên bố rằng đồng thời là dễ dàng bởi vì mô hình của họ tránh được trạng thái có thể thay đổi. Tôi không hiểu

Tôi muốn đưa ra câu hỏi chung chung này với tư cách là một người có chức năng tân sinh nhưng đã bị ảnh hưởng đến nhãn cầu của tôi trong nhiều năm qua và muốn giảm thiểu chúng, vì mọi lý do, bao gồm dễ dàng hơn (hoặc cụ thể là "an toàn hơn," ít xảy ra lỗi ") đồng thời. Khi tôi liếc qua các đồng nghiệp chức năng của mình và những gì họ đang làm, cỏ có vẻ hơi xanh hơn và có mùi thơm hơn, ít nhất là về vấn đề này.

Thuật toán nối tiếp

Điều đó nói rằng, về ví dụ cụ thể của bạn, nếu bản chất của bạn là vấn đề nối tiếp và B không thể được thực thi cho đến khi A kết thúc, về mặt khái niệm bạn không thể chạy A và B song song bất kể điều gì. Bạn phải tìm cách phá vỡ sự phụ thuộc thứ tự như trong câu trả lời của mình dựa trên việc thực hiện các bước di chuyển song song bằng trạng thái trò chơi cũ hoặc sử dụng cấu trúc dữ liệu cho phép các phần của nó được sửa đổi độc lập để loại bỏ sự phụ thuộc đơn hàng như đề xuất trong các câu trả lời khác hoặc một cái gì đó thuộc loại này. Nhưng chắc chắn có một phần các vấn đề thiết kế khái niệm như thế này, nơi bạn không nhất thiết chỉ là đa luồng mọi thứ một cách dễ dàng bởi vì mọi thứ là bất biến. Một số thứ sẽ được nối tiếp trong tự nhiên cho đến khi bạn tìm ra một cách thông minh để phá vỡ sự phụ thuộc đơn hàng, nếu điều đó thậm chí có thể.

Đồng thời dễ dàng hơn

Điều đó nói rằng, có nhiều trường hợp chúng tôi không song song hóa các chương trình liên quan đến tác dụng phụ ở những nơi có khả năng cải thiện hiệu suất đáng kể chỉ vì khả năng nó có thể không an toàn cho chuỗi. Một trong những trường hợp loại bỏ trạng thái có thể thay đổi (hay cụ thể hơn là tác dụng phụ bên ngoài) giúp ích rất nhiều vì tôi thấy nó biến "có thể hoặc không an toàn cho luồng" thành "chắc chắn an toàn cho luồng" .

Để làm cho tuyên bố đó cụ thể hơn một chút, hãy xem xét rằng tôi giao cho bạn một nhiệm vụ để thực hiện một chức năng sắp xếp trong C chấp nhận một bộ so sánh và sử dụng điều đó để sắp xếp một mảng các phần tử. Nó có nghĩa là khá khái quát nhưng tôi sẽ cho bạn một giả định dễ dàng rằng nó sẽ được sử dụng để chống lại các yếu tố đầu vào có quy mô như vậy (hàng triệu yếu tố trở lên) mà chắc chắn sẽ có ích khi luôn sử dụng triển khai đa luồng. Bạn có thể đa chức năng sắp xếp của bạn?

Vấn đề là bạn không thể bởi vì các bộ so sánh gọi chức năng sắp xếp của bạn có thểgây ra tác dụng phụ trừ khi bạn biết cách chúng được thực hiện (hoặc ít nhất là được ghi lại) cho tất cả các trường hợp có thể xảy ra mà không thể làm suy giảm chức năng. Một bộ so sánh có thể làm một cái gì đó kinh tởm như sửa đổi một biến toàn cục bên trong theo cách phi nguyên tử. 99.9999% bộ so sánh có thể không làm điều này, nhưng chúng tôi vẫn không thể đa chức năng tổng quát hóa chức năng này đơn giản chỉ vì 0,00001% trường hợp có thể gây ra tác dụng phụ. Kết quả là bạn có thể phải cung cấp cả hàm sắp xếp một luồng và đa luồng và chuyển trách nhiệm cho các lập trình viên sử dụng nó để quyết định sử dụng cái nào dựa trên sự an toàn của luồng. Và mọi người vẫn có thể sử dụng phiên bản một luồng và bỏ lỡ các cơ hội để đa luồng vì họ cũng có thể không chắc chắn liệu bộ so sánh có an toàn cho luồng hay không,

Có rất nhiều trí tuệ có thể tham gia vào việc hợp lý hóa sự an toàn của mọi thứ mà không cần ném khóa ở mọi nơi có thể biến mất nếu chúng ta chỉ đảm bảo chắc chắn rằng các chức năng sẽ không gây ra tác dụng phụ cho hiện tại và tương lai. Và có nỗi sợ: nỗi sợ thực tế, bởi vì bất kỳ ai phải gỡ lỗi một điều kiện cuộc đua quá nhiều lần có lẽ sẽ do dự về việc đa luồng bất cứ điều gì mà họ không thể chắc chắn 110% là an toàn theo luồng và sẽ vẫn như vậy. Ngay cả đối với những người hoang tưởng nhất (trong đó tôi có lẽ ít nhất là đường biên giới), chức năng thuần túy mang lại cảm giác nhẹ nhõm và tự tin mà chúng ta có thể gọi nó một cách an toàn song song.

Và đó là một trong những trường hợp chính mà tôi thấy nó rất có lợi nếu bạn có thể đảm bảo chắc chắn rằng các chức năng đó là an toàn theo luồng mà bạn có được với các ngôn ngữ chức năng thuần túy. Khác là các ngôn ngữ chức năng thường thúc đẩy việc tạo các chức năng không có tác dụng phụ ở nơi đầu tiên. Ví dụ, họ có thể cung cấp cho bạn các cấu trúc dữ liệu liên tục trong đó khá hợp lý để nhập cấu trúc dữ liệu lớn và sau đó xuất một cấu trúc hoàn toàn mới chỉ với một phần nhỏ thay đổi so với ban đầu mà không cần chạm vào bản gốc. Những người làm việc mà không có cấu trúc dữ liệu như vậy có thể muốn sửa đổi chúng trực tiếp và mất một số an toàn luồng trên đường đi.

Tác dụng phụ

Điều đó nói rằng, tôi không đồng ý với một phần với tất cả sự tôn trọng với những người bạn chức năng của tôi (người mà tôi nghĩ là rất tuyệt):

[...] Bởi vì mô hình của họ tránh được trạng thái đột biến.

Nó không nhất thiết là bất biến làm cho đồng thời trở nên thiết thực như tôi thấy. Đó là chức năng tránh gây ra tác dụng phụ. Nếu một hàm nhập một mảng để sắp xếp, sao chép nó và sau đó biến đổi bản sao để sắp xếp nội dung của nó và xuất ra bản sao, thì nó vẫn an toàn như luồng khi làm việc với một số loại mảng bất biến ngay cả khi bạn chuyển cùng một đầu vào mảng đến nó từ nhiều chủ đề. Vì vậy, tôi nghĩ rằng vẫn còn một nơi cho các loại có thể thay đổi trong việc tạo mã rất thân thiện đồng thời, có thể nói, mặc dù có rất nhiều lợi ích bổ sung cho các loại bất biến, bao gồm các cấu trúc dữ liệu liên tục mà tôi sử dụng không nhiều cho các thuộc tính bất biến của chúng nhưng loại bỏ chi phí phải sao chép sâu mọi thứ để tạo ra các chức năng không có tác dụng phụ.

Và thường có chi phí cao để tạo ra các chức năng không có tác dụng phụ dưới dạng xáo trộn và sao chép một số dữ liệu bổ sung, có thể là một mức độ gián tiếp bổ sung và có thể là một số GC trên các phần của cấu trúc dữ liệu liên tục, nhưng tôi nhìn vào một người bạn của tôi có một cỗ máy 32 lõi và tôi nghĩ việc trao đổi có lẽ đáng giá nếu chúng ta có thể tự tin làm nhiều việc hơn song song.